AI agent security testing exposes the limits of IAM-first thinking

At a glance

What this is: This is an analysis of Straiker’s AI agent security testing and runtime protection model, with the key finding that AI safety validation does not substitute for enterprise identity controls.

Why it matters: IAM teams need to separate AI security testing from access governance because agentic systems still depend on identity, privilege, and audit controls across NHI, autonomous, and human access paths.

By the numbers:

• Straiker emerged in 2025 and raised $21 million from Lightspeed Venture Partners and Bain Capital Ventures.

👉 Read WorkOS's analysis of Straiker for AI agent security

Context

AI agent security testing has become a distinct category because conventional application security tools do not fully capture prompt injection, data leakage, or unsafe tool use in agentic systems. The governance problem is broader than testing alone: when an AI agent can access data, call tools, and act inside enterprise workflows, identity and authorization controls still determine the boundary of acceptable behaviour.

Straiker’s framing is a useful reminder that security validation and identity governance solve different problems. Testing can surface weaknesses before deployment and monitor for abuse in production, but it does not answer who is allowed to connect an agent to systems, what the agent may do once connected, or how those permissions are reviewed over time.

Key questions

Q: How should security teams govern AI agents that can call tools and access data?

A: Treat the agent as a governed identity, not just an application feature. Security teams should define the agent’s permissible tools, bound its data access, and require logs that tie every action back to an attributable identity chain. Testing helps validate behaviour, but authorization, revocation, and review still belong to IAM and NHI governance.

Q: Why do AI security testing tools not replace IAM controls for agents?

A: Because testing answers whether the agent behaves safely, while IAM answers who may access it and under what conditions. Those are different control functions. If an agent can reach enterprise systems, you still need access provisioning, audit evidence, and revocation processes that work at the identity layer, not just the model layer.

Q: What do teams get wrong when they rely only on runtime detection for AI agents?

A: They confuse visibility with governance. Runtime detection can show suspicious behaviour after or during execution, but it does not prevent over-permissioned access, shared tokens, or poorly scoped service accounts from being used in the first place. Effective control starts with permission design and identity evidence, then uses detection to confirm boundaries are holding.

Q: Should organisations evaluate AI agent security tools before or after identity controls are in place?

A: After the identity foundation is clear. Organisations should first establish authentication, authorization, logging, and token governance for the agent, then layer in security testing and runtime monitoring. Without that sequence, the organisation may detect risk but still lack the evidence needed to contain it or assign accountability.

Technical breakdown

Autonomous red teaming for AI agents

Autonomous red teaming uses adversarial scenarios to probe an AI agent for weaknesses without relying on a human to script every test case. In practice, the testing system generates attack paths for prompt injection, jailbreak attempts, data exfiltration, and unsafe tool invocation. That matters because agent behaviour changes as prompts, tools, memory, and model outputs change. Continuous testing is useful when the control objective is to validate that an agent stays within expected safety boundaries as the system evolves.

Practical implication: treat autonomous red teaming as a validation layer, not as a substitute for agent identity, authorization, or lifecycle governance.

Runtime threat detection in agentic pipelines

Runtime protection monitors agent interactions while the system is live, looking for suspicious prompts, anomalous tool calls, and data exposure patterns. In an agentic pipeline, the key technical issue is that execution happens across several components: model inference, tool orchestration, external APIs, and logging. A low-latency detector can spot misuse quickly, but it only works well when the environment exposes clean telemetry and when the agent's permissions are already bounded. Detection is a response mechanism, not a permissioning model.

Practical implication: instrument tool calls, token use, and data flows so runtime detection can actually see the decision path it is meant to inspect.

Why AI security testing does not replace authentication and audit

AI security testing focuses on whether an agent behaves safely under attack, while authentication and audit determine who can access the agent and what actions are attributable. Those are different control planes. If an enterprise connects an agent to customer data, enterprise systems, or privileged APIs, the identity layer still governs session establishment, user binding, directory sync, and evidence generation. Without that foundation, you can detect unsafe behaviour and still be unable to prove who authorised it or revoke access cleanly.

Practical implication: map agent security tooling to existing IAM and audit controls rather than assuming one product category can cover both.

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

AI agent security testing is necessary, but it sits above the real governance boundary. Autonomous red teaming and runtime monitoring can reduce exposure, but they do not define who should have access, what privilege is appropriate, or how accountability is preserved. That means the enterprise still needs identity governance beneath the testing layer. Practitioners should avoid mistaking validation for control.

AI agent security is creating a split between safety testing and identity control. The market is now separating tools that look for prompt injection and runtime misuse from tools that govern access, entitlement, and auditability. That split matters because most enterprise risk decisions still happen in identity programmes, not in model-safety tooling. Practitioners need to decide where that boundary lives before agent sprawl creates unmanaged access paths.

Agent access without identity-led governance is still a privilege problem, even when the agent is well tested. A secure test harness does not prevent overreach in production if the connected accounts, tokens, or API permissions remain broad. This is a classic NHI pattern: the attack surface is not only the agent model, but also the standing access attached to it. Practitioners should treat AI agent security as an extension of NHI governance, not a replacement for it.

Runtime detection helps, but it cannot close the assurance gap created by delegated agent action. Once an agent can act inside live workflows, the organisation must be able to explain what was authorised, by whom, and under what conditions. That is where audit, policy, and access review still carry the governance burden. Practitioners should expect agent security tooling to support evidence, not define responsibility.

From our research:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader NHI baseline, read Ultimate Guide to NHIs , 2025 Outlook and Predictions for how identity governance expectations are shifting.

What this signals

AI agent security will increasingly split into two buying motions: one for model safety validation and one for identity governance. Organisations that treat those as the same problem will overinvest in testing and underinvest in entitlement design, revocation, and audit evidence. With 92% of organisations saying governing AI agents is critical but only 44% having implemented policies, according to AI Agents: The New Attack Surface report, the gap is already operational.

The stronger programme response is to define an agent identity boundary before production scale creates shadow access paths. That means aligning security testing with NHI controls, not using testing as a proxy for authorization decisions. Teams should also expect compliance pressure to rise as more agent actions become delegated rather than directly human-initiated.

For practitioners

• Separate validation from authorisation Map AI security testing to the controls it can influence, then assign identity, access, and audit ownership to IAM or NHI governance teams. Do not let runtime testing become the implicit approval mechanism for production access.
• Inventory every agent-facing account and token List the service accounts, API keys, OAuth grants, and privileged API scopes attached to each deployed agent. Confirm which ones have standing access, which ones are shared, and which ones can be revoked without breaking production.
• Bind agent activity to attributable identity evidence Ensure logs capture the human approver, the agent instance, the connected workload identity, and the downstream tools invoked. Without that chain of evidence, runtime alerts may be visible but not actionable for investigation or recertification.
• Review prompt, tool, and data boundaries together Test agent behaviour against the actual permissions it holds, not just the model prompt or application layer. Scope the agent to the minimum data sources and tool actions required for the use case, then recheck those boundaries whenever the workflow changes.

Key takeaways

• AI agent security testing improves validation, but it does not establish who is allowed to connect an agent to enterprise systems.
• The practical risk is overconfidence: organisations can detect prompt injection while still leaving broad tokens, service accounts, and API scopes in place.
• IAM teams should govern agent identity, entitlement, and auditability first, then use security testing to confirm those boundaries are holding.

Key terms

• Agentic AI Security Testing: Testing that probes an AI agent for unsafe behaviour, data leakage, and tool misuse before or during production use. It focuses on how the agent responds under adversarial conditions, but it does not replace identity governance, authorization design, or auditability.
• Runtime Threat Detection: Monitoring that watches live agent activity for suspicious prompts, anomalous tool use, and signs of data exposure. It is a detection layer, not a permissioning model, and it only works well when telemetry is available and the agent’s access has already been bounded.
• Agent Identity Boundary: The set of rules and controls that define which human users, workload identities, and permissions may connect to an AI agent. In practice, it is the point where governance decides what the agent can see, call, or delegate, and what evidence will prove those decisions.

Deepen your knowledge

AI agent identity and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic systems that touch enterprise data, it is worth exploring.

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