Snyk Evo and the limits of agentic security for AI agents

At a glance

What this is: This is a WorkOS analysis of Snyk’s Evo preview and the boundary between AI security scanning and enterprise identity control.

Why it matters: It matters because IAM teams cannot treat agentic security tools as substitutes for authentication, authorization, lifecycle governance, or audit controls across NHI and human identity programmes.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read WorkOS's analysis of Snyk Evo and agentic AI security limits

Context

Snyk’s move into agentic security sits in a familiar governance gap: organisations keep adding AI security tooling, but the control plane for identity, access, and accountability still sits elsewhere. In practical terms, scanning AI systems for vulnerabilities does not answer the more basic question of who or what is allowed to act on behalf of the business.

For IAM leaders, the distinction matters across AI agents, service identities, and human access. A tool that can test prompts, detect risky behaviour, or flag model issues may improve visibility, but it does not create enterprise authentication, authorisation, or lifecycle governance for the identities that touch production systems.

This makes the topic less about one vendor’s preview and more about programme design. The real issue is whether teams are building security around agent behaviour alone, or around the identity guarantees that make agent behaviour governable in the first place.

Key questions

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

A: Security teams should govern AI agents like non-human identities with explicit authentication, narrow authorisation, and short-lived access. Logging and behaviour analysis are useful, but they do not replace least privilege or lifecycle control. The key test is whether the agent can be scoped, reviewed, and revoked like any other privileged identity before it reaches production systems.

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

A: AI security scanning finds vulnerabilities, risky prompts, and unsafe behaviour patterns, but it does not prove who the agent is or what it may access. Production governance still requires identity, authorisation, and audit controls. Without those, organisations can detect problems while leaving the same identity able to repeat them.

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Should organisations use experimental agentic security tools in production?

A: Organisations should be cautious. Experimental agentic tools can be useful in testing and design partner environments, but production use demands stable access boundaries, clear ownership, and rollback procedures. If the tool influences live authorisation paths or handles sensitive identities, the preview label becomes a governance risk rather than a feature.

Technical breakdown

Why agentic security orchestration is not identity control

Agentic security orchestration means using AI-driven workflows to scan, test, classify, or remediate software and AI systems. That is useful for detection and analysis, but it is not the same as asserting identity, issuing tokens, or constraining authorisation. The control boundary matters because a security agent can observe or recommend actions without being the identity authority that grants access to systems, data, or APIs. In enterprise environments, authentication and authorisation must remain explicit, auditable, and policy-bound. Without that separation, organisations confuse security telemetry with actual access governance.

Practical implication: keep security orchestration and identity enforcement in separate control planes, with agent access governed by enterprise IAM rather than by the security tool itself.

Experimental previews create governance risk when they touch production paths

A preview system can be valuable for testing, but preview status is not just a product label. It signals evolving controls, changing behaviour, and incomplete production assurances. That becomes a governance issue when the system is asked to assess, influence, or operate on identities that already have access to sensitive workloads. In AI programmes, this is where policy, audit, and change management have to be stricter than the marketing language around autonomy. The security question is not whether the system is intelligent enough. It is whether its decisions are stable, reviewable, and reversible in the environments where identity trust matters most.

Practical implication: treat preview agentic tooling as non-production until its access paths, audit trails, and rollback controls are proven in controlled environments.

AI agent observability does not solve authorisation sprawl

Observability tells you what an AI agent did, but authorisation determines whether it should have been able to do it at all. That distinction is central in NHI governance because agents often operate through delegated service identities, APIs, and shared credentials. If the agent can reach too many tools, data stores, or admin functions, telemetry only documents the overreach after the fact. Real control requires scope design, credential hygiene, and lifecycle governance for the identities behind the automation. In other words, visibility helps investigation, but permissioning prevents blast radius.

Practical implication: define agent permissions before deployment and validate them against least-privilege boundaries, not against post hoc behavioural logs.

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

Security scanning and enterprise identity are different control problems: The article correctly separates vulnerability analysis from authentication, but the market still blurs them in practice. Agentic tooling can find risky behaviour in AI systems, yet it cannot establish who the agent is, what it may access, or how its privileges expire. That makes identity the governable layer and scanning the supporting layer, not the reverse. Practitioners should treat security orchestration as evidence generation, not as an access authority.

Experimental agentic security creates a governance gap when it is treated as production control: A preview system is not just immature software, it is a moving control boundary. If teams wire preview agents into workflows that touch enterprise data or production systems, they inherit unclear accountability, unstable authorisation behaviour, and weak change control. The issue is not that experimentation is wrong, but that preview semantics cannot carry production-grade identity assurance. Practitioners should separate evaluation environments from enforceable access policy.

Identity blast radius is the named concept this market is converging on: AI agents can scan more, act faster, and touch more systems than the humans who manage them can review in real time. That expands the identity blast radius whenever access is delegated without tight scope, short-lived credentials, and clear ownership. The practical consequence is that governance must start from the maximum damage an identity can do, not from the novelty of the security workflow. Practitioners should design around containment first.

Workflows that secure AI are not the same as controls that govern AI access: The article’s deeper lesson is that security teams can gain confidence from testing while still leaving authorisation unchanged. That is a structural mismatch, not a tooling gap. If the same identity can still reach broad systems after the test succeeds, the programme has improved detection without reducing privilege. Practitioners should measure success by access reduction and accountability, not by how many issues a scanning workflow can surface.

From our research:

• 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 AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• For a broader view of the category risk, OWASP NHI Top 10 maps the main failure modes that show up when agents combine tools, data, and delegated access.

What this signals

Agentic security will keep expanding, but identity governance has to become more explicit, not more implicit. The control gap is not whether AI systems can be tested, but whether the organisation can explain and constrain the identities they use in production. With 98% of companies planning to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report, the pressure is now on access design, not experimentation.

Identity blast radius is the operational signal IAM teams should watch. If an AI workflow can still reach sensitive systems after a scan, the programme has improved detection without reducing exposure. That is why agent permissions, revocation paths, and delegated access scope should be tracked as primary governance metrics, not side effects of security tooling.

Teams that already operate NHI governance can absorb this shift faster because the underlying logic is the same: know the identity, constrain the privilege, and prove the revocation path. The difference with AI agents is that the behavioural surface is wider, so governance has to be tighter at the point of delegation.

For practitioners

• Separate security testing from identity authority Keep agentic scanning, red teaming, and policy analysis out of the access decision path. Production systems should rely on explicit enterprise IAM and PAM controls for any identity that can call APIs, reach data, or trigger actions.
• Inventory every identity behind AI workflows Map the human administrators, service accounts, API keys, and tokens that the AI system uses. Include the system owner, approval path, and revocation owner for each identity so access can be reviewed and withdrawn without guessing.
• Restrict preview agents to non-production scopes Limit experimental agentic tools to isolated environments with tightly bounded data, short-lived credentials, and explicit rollback. If a preview workflow can reach production systems, it is already part of the identity control plane.
• Measure permission reduction, not just detection volume Track whether the AI programme actually shrinks reachable systems, sensitive data exposure, and standing privilege. A growing list of findings is not a control outcome if the identity can still perform the same actions.

Key takeaways

• AI security scanning and enterprise identity governance solve different problems, and the distinction matters most in production agent deployments.
• The scale of the blind spot is already material, with many organisations unable to fully audit what their AI agents access or do.
• The right response is to tighten authorisation, ownership, and revocation around AI identities, not to confuse testing tools with access controls.

Key terms

• Agentic Security Orchestration: A security workflow where AI-driven agents coordinate scanning, testing, classification, or remediation tasks across systems. It can improve speed and coverage, but it does not itself grant identity, authorisation, or lifecycle control over the assets being assessed.
• Identity Blast Radius: The maximum damage a single identity can cause if its access is too broad, poorly scoped, or difficult to revoke. In AI agent environments, blast radius expands quickly when delegated credentials can reach multiple tools, data stores, and admin functions without tight containment.
• Preview Control Surface: An evolving product or workflow boundary that is not yet stable enough to be treated as production-grade governance. In identity terms, preview controls may inform evaluation, but they should not be relied on to enforce access decisions or compliance obligations.
• Delegated Access: Access granted to one identity so it can act on behalf of another user, system, or workload. For AI agents, delegated access must be explicitly scoped and auditable because the agent may chain actions faster than human review cycles can respond.

Deepen your knowledge

AI agent identity governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building production AI systems with enterprise access, it is worth exploring.

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