AI agent security still needs identity controls beyond code scanning

At a glance

What this is: WorkOS argues that Semgrep addresses code security for AI-generated software, but not the authentication and authorization layer required for production AI agents.

Why it matters: IAM, NHI, and AI platform teams need to treat code scanning and identity control as separate problems, because secure code does not automatically produce secure agent access.

👉 Read WorkOS's analysis of Semgrep for AI agent security and enterprise identity

Context

AI agent security breaks when teams treat code quality as the same problem as identity control. Semgrep can scan code artifacts and surface vulnerabilities early, but it does not establish who or what the agent is, what it may access, or how its actions are governed at runtime. That separation matters for AI agent security because production systems need both secure code and controlled identity boundaries.

The article is really about a governance gap, not a scanner comparison. AI-generated code can be reviewed by static analysis, while the agent itself still requires authentication, authorization, auditability, and lifecycle control. For enterprises building agentic systems, the risk is assuming that secure code review solves access control. It does not.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Treat production AI agents as non-human identities, not just applications. They need explicit authentication, scoped authorisation, audit logging, and lifecycle ownership before they are allowed to act in enterprise environments. Code scanning helps reduce defects in what the agent does, but it does not control what the agent is allowed to do at runtime.

Q: Why is code scanning not enough for AI agent security?

A: Code scanning finds vulnerabilities in the software artefact, but it does not establish identity, privilege, or accountability for the runtime actor. An agent can run secure code and still be over-permissioned, unaudited, or impossible to revoke cleanly. Security teams need both application security controls and identity controls to reduce that gap.

Q: When should organisations add identity controls to AI development pipelines?

A: They should add identity controls as soon as an AI system can authenticate to internal tools, customer environments, or third-party APIs. That is the point where the risk shifts from code quality to runtime access governance. If the system can act outside the repo, it needs NHI-style control ownership.

Q: What is the difference between AI agent security and application security?

A: Application security focuses on the safety of the code and its execution paths. AI agent security also includes who the agent is, what it can access, how it is authorised, and how its access is revoked. In production, both disciplines are required because secure software does not automatically produce secure identity behaviour.

Technical breakdown

Why static application security testing stops at the code boundary

Static application security testing, or SAST, inspects source code or compiled artifacts for insecure patterns before deployment. That makes it useful for catching injection flaws, bad deserialisation logic, or broken access checks introduced by AI-assisted development. But SAST only sees the code a system will run, not the runtime identity of the system itself. It cannot tell whether an agent should be allowed to act, which resources it may touch, or whether its privileges are aligned to enterprise policy. In AI-heavy pipelines, that boundary is critical: code can be clean while identity remains unmanaged.

Practical implication: use SAST to reduce software defects, but keep identity and authorisation in a separate control plane.

MCP-based security workflows and the agent tool boundary

Model Context Protocol, or MCP, lets agents and AI tools request structured actions from external services. In security workflows, that can turn a scanner into an on-demand endpoint for finding and triage. The architectural risk is that tool access can look like governance when it is really just another integration surface. An MCP server may expose scans, findings, and rule execution, but it still does not create enterprise identity, enforce tenant boundaries, or govern which agent is entitled to invoke those tools. Tool availability is not the same as authorisation.

Practical implication: control MCP access as a tool interface, not as a substitute for enterprise authentication or privilege enforcement.

Why production AI agents need authentication and authorisation infrastructure

Production AI agents behave like non-human identities when they authenticate into customer systems, call APIs, or operate across enterprise environments. That means they need the same governance primitives as other machine identities: SSO where relevant, fine-grained authorisation, audit logging, provisioning, and deprovisioning. The article’s core boundary is accurate: secure code does not secure the executor. Without identity infrastructure, an agent can still overreach even if the code it runs is well scanned. The security model must govern both the software and the subject acting through it.

Practical implication: architect AI agents with NHI-style identity controls and lifecycle governance, not just application security checks.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code security and identity security are different control domains, and AI work has made that boundary visible. Static analysis can reduce defects in AI-generated code, but it cannot authorise the entity that runs the code or the resources it can touch. That distinction matters because many programmes now over-index on code review while leaving agent identity untreated. Practitioners should treat code scanning as one layer and identity governance as another.

Production AI agents are non-human identities first and software second. Once an agent authenticates into enterprise systems, it enters the same governance problem space as service accounts, API keys, and workload identities. That means access scope, auditability, and deprovisioning must be defined around the agent's operational role, not around the quality of the code it produced. Practitioners need NHI governance, not just developer security tooling.

Model Context Protocol creates a useful integration layer, but not an identity boundary. A tool that can request scans or findings on demand still does not decide who may invoke it, under what conditions, or with what standing privilege. The governance gap is the assumption that actionability equals control. Practitioners should separate tool orchestration from enterprise authorisation and keep both under different controls.

Identity governance for AI agents should be judged by runtime authority, not by repository hygiene. The article correctly frames Semgrep as useful for code artefacts and WorkOS as relevant to production access, but the broader lesson is structural: AI systems now span software supply, runtime execution, and enterprise access. Practitioners should align each layer to the control it actually needs, rather than collapsing them into a single security story.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• For the control model behind that gap, see OWASP Top 10 for Agentic Applications 2026 for the runtime-risk patterns practitioners need to map.

What this signals

Agent identity is becoming a separate governance domain from application security. As AI systems move from code generation into production access, teams will need a distinct inventory of non-human identities, approvals, and revocation paths. The organisations that keep treating agent security as a developer tooling problem will miss the governance layer that actually governs runtime reach.

The practical pressure point is auditability. If teams cannot tell which agents accessed which systems, they will struggle with compliance, incident response, and ownership questions even when code quality looks strong. That is why access visibility, not just code scanning, is becoming the operational control that separates pilot deployments from governed production use.

For practitioners

• Separate code scanning from access governance Keep SAST, code review, and AI-assisted triage in the engineering pipeline, but manage agent authentication, authorisation, and audit logging in a distinct identity stack.
• Inventory AI agents as non-human identities Record every production agent, service account, and token that can reach enterprise systems, then assign owners, approval paths, and deprovisioning criteria.
• Constrain MCP tool access explicitly Treat MCP endpoints as privileged tools, not neutral utilities, and restrict which agents can request scans, retrieve findings, or trigger downstream actions.
• Tie deployment readiness to identity controls Do not move an agent into production until it has fine-grained authorisation, audit logging, and a documented lifecycle path for revocation.

Key takeaways

• Semgrep addresses code defects, but AI agent security also depends on who can authenticate, act, and be revoked at runtime.
• Production AI agents should be governed as non-human identities, with scoped access, audit logging, and explicit lifecycle ownership.
• Security teams that blur code scanning and identity control will leave the most important part of agent governance unaddressed.

Key terms

• Static Application Security Testing: Static application security testing is the practice of analysing source code or compiled artefacts for insecure patterns before deployment. It is useful for finding defects in software, but it does not govern the runtime identity or access rights of the system that executes that code.
• Model Context Protocol: Model Context Protocol is an integration standard that lets AI tools and agents request structured access to external services. It simplifies orchestration, but it does not itself create enterprise identity, authorisation policy, or lifecycle governance for the actors using it.
• Non-Human Identity: A non-human identity is any machine or software identity that authenticates to systems on its own, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. The governance problem is not just possession of credentials, but ownership, scope, auditability, and revocation.
• Runtime Authorisation Boundary: A runtime authorisation boundary is the line that defines what an executing system may access or do while it is running. For AI agents, this boundary must be enforced separately from code review because the code can be safe while the actor remains over-permissioned.

Deepen your knowledge

AI agent identity and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are turning agentic systems into production services, this is the control model to study next.

This post draws on content published by WorkOS: Semgrep for AI Agent Security: Features, Pricing, and Alternatives. Read the original.