Agentic AI security at RSAC 2025 shows autonomy changed the threat model

At a glance

What this is: This RSAC 2025 recap argues that agentic AI has become an operational security issue, not a future concept, because autonomous systems can take actions that create new identity and privilege risk.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern systems that choose actions at runtime, not just identities that authenticate and then wait for policy enforcement.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

👉 Read Lasso Security's RSAC 2025 recap on agentic AI security and governance

Context

Agentic AI is software that can choose actions, call tools, and execute work without waiting for a person to approve each step. That changes the security problem from protecting a user session to governing an identity that can behave like an operator inside the environment. For IAM teams, the question is no longer only who authenticated, but what the system decided to do after authentication.

The post is about the gap between existing identity controls and autonomous behaviour. Traditional access models assume stable entitlements, predictable request flows, and reviewable states. Once an AI system can change its own execution path, those assumptions weaken, which is why agentic AI belongs in the same governance conversation as NHI, PAM, and lifecycle control.

Key questions

Q: How should security teams govern AI agents that can call multiple tools at runtime?

A: Security teams should govern AI agents as runtime identities, not static applications. That means defining task-scoped permissions, logging every tool invocation, and removing any access path the agent does not need for the current job. The control objective is to prevent broad inherited access from turning into uncontrolled action across systems.

Q: Why do AI agents complicate least-privilege access models?

A: AI agents complicate least privilege because their needed access can change during execution. A permission set that looks reasonable at provisioning time may become excessive once the agent selects a new tool or data source. Least privilege must therefore be tied to runtime context, not only to identity registration.

Q: What breaks when organisations treat agent visibility as enough governance?

A: Visibility alone breaks down when an agent can act faster than a review cycle and chain multiple actions before a human notices. You may see the activity, but still lack the boundaries that would have prevented it. Governance requires enforceable limits, not only dashboards and alerts.

Q: How do security teams decide whether an AI agent needs PAM-style controls?

A: Use PAM-style controls when the agent can reach sensitive systems, modify data, trigger administrative actions, or inherit privileges that exceed its task scope. The deciding factor is not whether the system is called an AI agent, but whether its actions can change operational state in ways that need tighter approval and session control.

Technical breakdown

Agentic AI security and runtime decision paths

Agentic AI security starts with the fact that these systems do not merely consume data. They select tools, decide when to act, and can chain actions across APIs, chat interfaces, and internal systems. That creates a runtime identity problem, because privilege is not just what was provisioned at start-up but what the system can reach mid-session. In practice, the control plane must account for intent drift, tool sprawl, and autonomous escalation paths that do not exist in conventional app workflows.

Practical implication: map the decision path, not just the account, and treat each tool invocation as an access event that requires boundary control.

Context-based access control for AI agents

Context-based access control is a policy model that considers task, data sensitivity, session state, and behavioural context before allowing action. For AI agents, this matters because the same identity may need very different permissions depending on which prompt, data source, or downstream system is involved. Without contextual limits, an agent can inherit broad user rights and then reuse them in situations that were never intended at provisioning time. That is how privilege escalation and data leakage become governance problems, not just security alerts.

Practical implication: bind permissions to task context and revoke any access path that is not explicitly needed for the current action.

MCP, tool execution boundaries, and oversight

The Model Context Protocol, or MCP, standardises how agents connect to tools and data sources, which makes governance more urgent rather than less. Standardisation helps interoperability, but it also creates repeatable execution paths that attackers can abuse if permissions, logging, and approval boundaries are weak. For security teams, the architectural question is whether the agent can only request bounded actions or whether it can expand into new tools and higher-risk workflows without a fresh control check.

Practical implication: inventory every MCP-connected tool, then enforce least privilege and logging at the tool boundary rather than assuming the agent layer will self-limit.

Threat narrative

Attacker objective: The attacker objective is to abuse legitimate agent access to reach sensitive systems, leak data, or trigger actions the organisation never intended.

1. Entry occurs when an agent is given legitimate access to enterprise data, APIs, or tools as part of normal deployment.
2. Escalation happens when the agent uses that access to chain additional tool calls, reach higher-value systems, or act outside the intended task scope.
3. Impact follows when the chained actions expose data, trigger unauthorised system behaviour, or create a larger attack surface than the organisation expected.

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

Autonomous identity review is a broken assumption, not just a missing control. Access review processes were designed for identities whose privileges remain stable long enough to be observed, certified, and remediated. That assumption fails when an autonomous actor can acquire, combine, and discard access inside a single operational session. The implication is that governance programmes must rethink what counts as an auditable entitlement state, because the old review cadence no longer matches the actor's behaviour.

Context-based access control is becoming the decisive line between contained agent action and privilege drift. The Lasso recap reinforces a field-wide shift: the risk is no longer that AI agents exist, but that they can inherit broad enterprise permissions and reuse them in unplanned ways. This is the same failure mode that OWASP-NHI and zero-trust models try to contain in machine identity, now applied to agents that make runtime decisions. Practitioners should treat agent context as an access boundary, not a logging detail.

Agentic AI security is collapsing the boundary between NHI governance and application security. The post shows that visibility, guardrails, and compliance are converging on one question: what can the system do after it is authenticated? That question sits between IAM, PAM, NHI, and AI governance, which is why siloed ownership no longer works. Practitioners need one governance model that can follow the identity from provisioned access to runtime action.

Model Context Protocol creates a repeatable execution fabric, which also creates repeatable abuse paths. Protocol standardisation helps teams integrate tools faster, but it also makes tool boundaries more predictable for attackers and easier to misconfigure at scale. The named concept here is runtime governance gap: the separation between where access is granted and where action is actually taken. Security teams should treat that gap as a design problem, not an after-the-fact detection problem.

The market is converging on agent visibility, but governance maturity is still lagging behaviour. Survey data in the post shows strong concern about AI agents, yet practical control adoption remains uneven. That pattern is familiar from earlier NHI growth curves: enthusiasm rises faster than identity policy, auditability, and lifecycle discipline. Practitioners should assume that agent populations will expand before governance catches up.

From our research:

• 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, 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.
• For a broader control model, see OWASP Agentic Applications Top 10 for the identity and privilege risks that emerge when agents act at runtime.

What this signals

Runtime governance gap: the biggest operational issue is not whether organisations will adopt AI agents, but whether they can constrain those agents after deployment. The control plane now has to follow tool calls, data access, and downstream actions in real time, which is a different burden from traditional app security.

The post's signal is that agent visibility, compliance reporting, and access control are converging into one programme problem. Teams that already govern machine identities should extend the same discipline to agent identities, then align it with zero-trust thinking and the OWASP Agentic AI model. CSA MAESTRO agentic AI threat modeling framework is one useful external reference point.

With 92% of respondents saying AI agent governance is critical but only 44% reporting any policy implementation, the gap is no longer awareness. It is execution, and that means access boundaries, logging, and lifecycle ownership have to be designed before agent populations scale further.

For practitioners

• Inventory every AI agent and its tool graph Document each agent, the data sources it can reach, the APIs it can call, and whether any path allows escalation beyond the original task scope. Include shadow deployments and embedded agents in business applications, not just formal AI projects.
• Bind permissions to task context Set policies so access depends on prompt, workflow state, data classification, and session purpose. Remove broad inherited permissions where a smaller, task-scoped boundary is sufficient.
• Put logging at the tool boundary Capture every tool invocation, data retrieval, and outbound action at the point of execution. That gives you the evidence needed to reconstruct autonomous behaviour when the agent takes a path no human expected.
• Review MCP-connected systems as identity surfaces Treat each MCP-connected tool as a privileged integration point with its own approval, logging, and least-privilege requirements. Do not assume the agent layer will provide enough control by itself.

Key takeaways

• Agentic AI changes identity governance because the system can decide and act at runtime, not just authenticate and wait.
• The evidence in the post shows that most organisations already see AI agents overstep intended scope, which turns governance into an immediate control problem.
• Practitioners should treat tool boundaries, contextual permissions, and runtime auditability as core identity controls for AI agents.

Key terms

• Agentic AI: Software that can select actions, call tools, and carry work forward without waiting for a person at every step. In identity terms, it behaves like a runtime actor, which means permissions, logging, and review must follow what it does, not just what it was assigned.
• Context-based access control: A policy model that grants or denies access using task state, data sensitivity, session context, and behavioural signals. For AI agents, this is more precise than static provisioning because the same identity may pose different risk depending on what it is doing right now.
• Runtime governance gap: The distance between when access is granted and when an actor actually performs an action. In autonomous and agentic environments, that gap matters because risk often appears during execution, after traditional provisioning or review has already completed.
• Tool boundary: The control point where an AI agent, service account, or workload is allowed to call a specific system, API, or data source. Strong tool boundaries narrow blast radius, create audit evidence, and make escalation harder when behaviour changes at runtime.

Deepen your knowledge

Agentic AI security, runtime access control, and identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to extend IAM discipline into AI-driven systems, this is a practical place to start.

This post draws on content published by Lasso Security: RSAC 2025 recap on agentic AI, global recognition, and GenAI security. Read the original.