Ask Claude or GPT to write a login handler, a file-upload endpoint, or a SQL query, and you will get working code fast. Whether that code is safe depends less on which model you picked and more on the harness wrapped around it: what tools it can call, what it can execute without asking, and whether anything downstream checks the output before it reaches a repository. Coding harnesses such as Claude Code, GitHub Copilot Workspace, Cursor, and OpenAI's Codex CLI now write, run, and commit code with minimal human review on many teams, which means model behavior on vulnerable code is no longer an academic question about benchmark scores -- it is a live production risk. This post compares how Claude and GPT tend to behave on classic vulnerable-code patterns inside real coding harnesses, then contrasts Safeguard's approach to catching what slips through against Endor Labs' reachability-first SCA model, on dimensions a buyer can verify independently rather than take on faith.
Why does model behavior on vulnerable code even matter inside a harness?
A coding harness is not just a model with a chat window. It is a model plus a permission system: which shell commands it can run, which files it can write, which MCP servers or plugins it can call, and whether a human has to approve each step or the agent can loop autonomously through several actions before anyone looks. That structure changes what "vulnerable code" means in practice. A model that suggests an unsafe SQL query in a chat window is a code-quality problem a reviewer catches on the next pull request. The same suggestion accepted inside an autonomous agent loop that also has shell access, package-install permission, and auto-commit enabled is a different risk category, because the vulnerable code, the dependency that shipped it, and the commit that introduced it can all happen inside one unattended session. Most public discussion of "AI and code security" still treats this as a single question -- does the model write secure code -- when it is really three layered questions: what the model outputs, what the harness lets it do with that output, and what checks the pipeline runs before the change ships. Comparing Claude and GPT only on the first layer misses where most of the actual exposure sits.
How do Claude and GPT actually behave on classic vulnerable-code patterns?
The most-cited data point here is still the Stanford research from Perry et al. ("Do Users Write More Insecure Code with AI Assistants?"), which found that developers using an AI code assistant introduced more vulnerabilities in categories like SQL injection and improper input validation than a control group, while also rating their own code as more secure than the control group did. Follow-on academic work testing Copilot- and Codex-era models against the MITRE CWE Top 25 found broadly similar patterns: default completions were frequently syntactically correct and functionally working, but not secure-by-default for injection, path traversal, and weak cryptographic primitives unless the prompt or surrounding code explicitly steered the model toward a safe pattern. Both Anthropic and OpenAI have since published safety and usage policies that shape refusal behavior for clearly malicious requests, such as generating a working exploit for a named, unpatched CVE. That refusal layer targets intent, not code quality on ordinary feature requests -- it does not function as a security linter. A harness asked to "add a search endpoint" or "parse this uploaded file" gets essentially no built-in security review from either model family, because neither vendor's safety training was designed to catch CWE-89 or CWE-22 in benign-looking code. The practical takeaway for a security team is that Claude-versus-GPT is the wrong axis to spend evaluation time on here; both need the same downstream scanning regardless of which one authored the diff.
Does Endor Labs' reachability analysis reach into the coding harness itself?
Endor Labs is publicly positioned around reachability-first software composition analysis: it builds a call graph across an application's dependency tree and determines whether a known-vulnerable function in an open source package is actually reachable from application code, which is a genuinely useful way to cut SCA noise. That analysis runs against code that already exists in a repository or build artifact. It is a downstream, post-commit check, not a control that sits inside the coding harness session itself. It has no visibility into what an autonomous coding agent did before the commit landed: which shell commands it ran, which MCP tools or plugins it invoked, whether it installed a package that is not yet in the lockfile, or whether a tool call touched a secret on disk. That is a defensible scope decision -- SCA and agent-runtime monitoring are different problems, and Endor Labs has never marketed itself as the latter -- but it means reachability analysis, however accurate, only ever sees the artifact a harness produced, never the session that produced it. For teams whose primary AI-generated-code risk is "what did the agent actually do with its tool access," a reachability-only SCA tool is necessary but not sufficient.
How does reachability-first prioritization compare once AI-generated code enters the SBOM?
Endor Labs deserves credit for popularizing reachability as the primary noise-reduction signal for open source dependency risk, and that architectural bet has held up well against flat CVE-count scanning. Safeguard's Griffin AI applies the same underlying principle -- is the vulnerable function actually callable from running code -- but widens the aperture beyond the dependency graph alone. Reachability in Griffin AI is one input alongside cloud exposure (is the reachable path actually deployed and internet-facing), KEV and zero-day intelligence, and container-image composition, so a vulnerable pattern an AI agent introduces gets weighted by whether it is deployed and exposed, not only whether it is syntactically callable. The two platforms therefore reduce noise using the same core idea, and the concrete difference a buyer can check is scope: Endor Labs' reachability graph covers the open source dependency tree; Safeguard's correlation layer covers that graph plus the container and runtime context the code ships in. Neither claim requires taking anyone's marketing at face value -- both are verifiable by feeding each platform the same SBOM and comparing what additional context comes back beyond a reachable-or-not flag.
What does a coding-harness-aware supply chain program actually need?
Three controls have to work together, and none of them alone covers the gap. First, CI policy gates that block a build on hardcoded secrets, insecure deserialization, or missing input validation regardless of whether a human or an agent wrote the diff -- the gate does not care who typed it. Second, dependency and SBOM scanning that catches vulnerable or non-existent packages a harness pulled in, including the now well-documented package-hallucination risk where a model invents a plausible-sounding package name that an attacker has pre-registered, sometimes called slopsquatting; multiple vendors and academic groups have published research on this pattern independently of any one vendor's marketing. Third, harness-level controls that most SCA tools were never built to provide: scoped tool permissions, sandboxed execution for anything an agent runs, an allowlist for which MCP servers or plugins a session can reach, and an audit log of what the agent actually did so an incident is reconstructable after the fact rather than inferred from a diff. A program built on only the first two controls will catch the vulnerable code the agent wrote but miss what the agent did with its shell and network access along the way.
How Safeguard Helps
Safeguard treats AI-generated code as code, not as a special exception, which means the same policy gates and SBOM ingestion pipeline apply whether a pull request came from a human, Claude, or GPT-based tooling. Griffin AI ingests SBOMs from your build pipeline and correlates dependency reachability with cloud exposure, KEV status, and zero-day intelligence, so a vulnerable pattern introduced by a coding agent is prioritized by whether it is actually deployed and reachable, not just present in a lockfile. Policy gates in CI enforce zero-CVE container image standards and block builds on hardcoded secrets or disallowed dependency patterns before merge, closing the review gap that unattended agent sessions can otherwise skip past. On the harness side, Safeguard's agent and MCP visibility work covers tool-permission scoping, shadow MCP server detection, and secret-handling checks for coding agent sessions, giving security teams the session-level audit trail that dependency-graph analysis alone cannot produce. TPRM scoring extends the same rigor to the AI coding tool vendors themselves, tracking certifications and disclosure history as part of the broader vendor risk file. The result is a program that does not need to re-litigate Claude versus GPT for every new coding assistant a team adopts, because the controls sit around the harness rather than depending on which model is inside it.