AI agent security still needs identity controls beyond code scanning

At a glance

What this is: This is an analysis of why code scanning for AI-generated code does not solve the separate problem of authenticating and authorising production AI agents.

Why it matters: IAM, IGA, PAM, and NHI teams need this boundary because secure code review does not replace identity controls for agents that access enterprise systems at runtime.

Context

AI agent security splits into two different control planes: securing the code an agent produces and governing the identity the agent uses at runtime. Static analysis can reduce coding defects, but it does not answer who or what is allowed to authenticate, request access, or act on a customer system.

This matters for agentic AI because production deployments create a non-human identity problem, not just a software quality problem. If an agent can sign in, call tools, or operate inside enterprise environments, the identity layer has to carry the access decision, the audit trail, and the revocation path.

WorkOS frames that boundary clearly: code scanning belongs in the development pipeline, while authentication, authorisation, federation, and audit logging belong in the operational identity layer. The split is familiar to identity practitioners, but AI agents make it impossible to ignore.

Key questions

Q: What breaks when AI agent security is handled like ordinary application security?

A: Application security assumes a relatively stable workload boundary and a predictable request path. AI agents can select tools, access data, and continue executing in ways that change the path mid-workflow. When teams treat them like static apps, they miss the identity and authorisation layer where real risk appears.

Q: Why do production AI agents need authorisation controls beyond secure code review?

A: Because secure code review cannot decide whether a runtime actor should have access to enterprise data, customer systems, or privileged APIs. Authorisation belongs to the identity layer, where scopes, entitlements, and session boundaries can be enforced independently of the code the agent produces.

Q: How do security teams know if an AI agent has too much access?

A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores. A healthy deployment leaves a clear audit trail of what the agent can do, what it actually did, and which credentials it used.

Q: What is the difference between securing the AI model and securing the code it generates?

A: Securing the model focuses on protecting the AI system from threats such as malicious prompts, injection, and misuse. Securing the code it generates focuses on the quality and safety of the output artifact itself. A model can behave as intended and still produce insecure code, so organisations need both input protection and output assurance before they can trust AI-assisted development.

Technical breakdown

Why static code analysis stops at the artifact boundary

Static application security testing inspects source code, configuration, and generated changes for patterns that look unsafe. It can catch injection flaws, insecure deserialisation, or weak auth checks in code paths, but it evaluates the artifact, not the runtime subject using it. That distinction matters for AI agents because a safe-looking codebase can still be executed by an identity with excessive reach. The control question is therefore not only whether the code is secure, but whether the actor running it is allowed to authenticate, request tools, and consume data in the first place.

Practical implication: Treat SAST as a code-quality control, not a runtime identity control.

Authentication and authorisation for AI agents are separate controls

Authentication proves which agent or service is acting, while authorisation decides what that actor may do after it is recognised. In agentic systems, those two steps cannot be collapsed into code review because the agent’s runtime behaviour may differ from the code that launched it. That is especially true when the agent uses enterprise SSO, OIDC, or delegated access into customer systems. The identity model must define the agent, its scopes, its session boundaries, and its revocation path independently of application logic. Without that separation, the agent inherits permissions implicitly rather than explicitly.

Practical implication: Design agent identity and access policies before deployment, not inside the code scanner.

Why AI agents create a non-human identity governance problem

Once an AI agent enters production, it behaves like a non-human identity with its own lifecycle, access scope, logging needs, and offboarding requirements. The governance challenge is not just whether the agent’s generated code is clean, but whether the agent itself can be provisioned, constrained, reviewed, and revoked like any other machine identity. That brings the problem into NHI governance, where standing privilege, auditability, and lifecycle management determine whether access remains controlled. Code scanning can reduce implementation defects, but it cannot govern the agent’s enterprise trust relationship.

Practical implication: Apply NHI lifecycle governance to agents that hold real operational access.

NHI Mgmt Group analysis

Code scanning and identity control solve different failure modes: static analysis reduces vulnerability density in generated code, but it does not establish who is allowed to act at runtime. That separation is not academic. A production AI agent can produce clean code and still be over-authorised, unaudited, or impossible to revoke cleanly. Practitioners should stop treating code security and identity security as substitutes.

AI agents expand the NHI problem, they do not replace it: once an agent authenticates into enterprise systems, it is operating as a non-human identity with access, lifecycle, and accountability requirements. That makes agent governance an extension of machine identity management, not a variation of application security. The right question is which controls govern the runtime actor, not which scanner inspected the output.

Authentication is the control plane that code scanners cannot emulate: code review can tell you whether a function is vulnerable, but it cannot decide whether the calling identity should exist, what it may reach, or when it must be removed. That is why enterprise SSO, federation, fine-grained authorisation, and audit logging remain separate requirements. The implication is straightforward: agent deployments need identity architecture, not only better defect detection.

Runtime privilege is the decisive risk variable for production agents: the same agent can be low risk in a sandbox and high risk when connected to customer data, admin APIs, or internal systems. The real governance question is therefore about scope, delegation, and revocation, not code generation speed. Practitioners should measure agent exposure by runtime entitlements rather than by scanning coverage.

Named concept: identity-aware agent deployment: production AI systems need a runtime identity layer that is independent of code quality tooling. This concept matters because the trust decision sits at authentication and authorisation time, while code scanning only informs secure implementation. Teams that collapse those layers will misplace control ownership and under-govern agent access.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Identity-aware agent deployment: AI agents should be governed as runtime identities, not treated as an extension of code quality tooling. That shift moves control ownership toward authentication, authorisation, audit, and offboarding, which are the levers that determine whether an agent can safely act in enterprise environments.

Access review processes work only when the subject retains a stable entitlement long enough to be reviewed. AI agents that authenticate dynamically and access systems through delegated scopes require issuance-time governance, because the meaningful control point is the grant itself, not a later recertification cycle.

Code security and identity security will increasingly diverge in mature agent programmes. Teams that invest in static analysis without equivalent runtime controls will reduce defects but leave the more consequential trust problem untouched.

For practitioners

• Separate code security from runtime identity governance Use SAST to inspect generated code, but define a distinct control plane for agent authentication, authorisation, audit logging, and revocation.
• Inventory every production agent as a non-human identity Track each agent’s system accounts, OAuth grants, API tokens, and delegated scopes so access can be owned and retired with the same discipline as other NHI credentials.
• Enforce least privilege at the agent boundary Scope each agent to the smallest set of resources and actions it needs, then review whether its session or delegation model creates standing access that outlives the task.
• Require auditability for enterprise-facing actions Log authentication events, authorisation decisions, and sensitive tool calls so investigators can reconstruct what the agent did and under which identity path.

Key takeaways

• The core issue is not whether AI-generated code is safe enough to deploy, but whether the runtime agent has been given identity and access controls that match its operational reach.
• Static analysis can reduce code defects, but it cannot govern authentication, authorisation, auditability, or revocation for production AI agents.
• Teams that want safe enterprise deployment need to treat AI agents as governed non-human identities, not as code artifacts with better linting.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Runtime identity governance: Runtime identity governance is the discipline of checking identity behaviour while access is being used, not just when it is granted or reviewed. It combines telemetry, policy comparison, and response so organisations can detect when access drifts from intent across distributed systems.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Non-Human Identity Lifecycle: The Non-Human Identity Lifecycle is the full sequence of creation, use, control, review, and retirement for identities that are not tied to a person. It covers service accounts, API keys, certificates, tokens, bots, and AI agents, including issuance, rotation, monitoring, revocation, and secure decommissioning across systems and environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.