Agentic AI is expanding the non-human identity attack surface

At a glance

What this is: This is an analysis of how agentic AI changes the non-human identity problem by giving software the ability to plan, remember, and act across enterprise systems.

Why it matters: It matters because IAM and NHI controls now need to govern autonomous behavior, not just static credentials and service accounts.

👉 Read Noma Security's analysis of agentic AI and non-human identity risk

Context

Agentic AI is a security and governance problem because the system can move from generating output to taking action. Once a model can call APIs, query databases, and operate across tools, it starts behaving like a non-human identity with access that must be scoped, reviewed, and revoked like any other production principal.

Noma Security’s framing is directionally consistent with what many IAM teams are now seeing in practice: AI agents are appearing inside business workflows before most organisations have defined ownership, lifecycle controls, or guardrails for them. That is an atypical starting position for identity governance, but it is becoming common as copilots, coding assistants, and workflow agents spread.

The key issue is not whether the model is intelligent, but whether the surrounding access model assumes autonomous execution. In NHI governance terms, that is a trust-boundary problem first and an AI problem second.

Key questions

Q: How should security teams govern AI agents that can take actions in production systems?

A: Security teams should govern AI agents as non-human identities with owners, scopes, approvals, and expiry rules. The access model should separate read from write permissions, require review for high-impact actions, and log prompts and tool calls so execution can be audited after the fact.

Q: Why do AI agents create more risk than traditional automation scripts?

A: AI agents can reason, remember context, and choose tools dynamically, which makes their behavior harder to predict than fixed automation. That flexibility increases the chance of unintended actions, privilege overreach, and audit gaps when the same identity can behave differently across sessions.

Q: What is the difference between an AI agent and a normal application integration?

A: A normal integration usually follows a fixed path with known inputs and outputs. An AI agent can decide what to do next, select tools on the fly, and act across multiple systems, which means its identity, permissions, and accountability need stronger governance than a static integration.

Q: When should organisations require human approval for agent actions?

A: Human approval is appropriate when an agent can change money, data, access rights, or production state. If the action is hard to reverse, affects other users, or creates compliance exposure, the decision should not be left to autonomous execution alone.

Technical breakdown

Why agentic AI behaves like a non-human identity

Traditional AI models generate recommendations, but agentic systems are connected to tools, data, and execution paths. That means the effective security object is not the model alone, but the model plus its credentials, tool permissions, memory, and goal state. Once an agent can retain context and trigger actions, it becomes a persistent identity with operational reach. The risk is amplified when access is inherited from the user who deployed it or when tool access is broader than the task requires. In practice, this creates a hybrid of application logic and identity risk that conventional application security does not fully cover.

Practical implication: Treat the agent as a governed principal and inventory every external system it can reach.

Tool access, memory, and reasoning create new failure modes

Agentic systems combine three security-sensitive properties: memory that persists across sessions, reasoning that can chain multiple steps, and tool access that can change real systems. Each property increases utility, but together they create more ways for prompts, misconfigurations, or malicious inputs to alter outcomes. A model with memory may reuse stale context, while a model with broad tool access can turn a small mistake into a real-world action. The result is not merely hallucination. It is uncontrolled execution under uncertain supervision, which is why policy and privilege boundaries need to sit outside the model itself.

Practical implication: Place hard limits on tool scope, session duration, and write permissions before enabling autonomous workflows.

MCP changes the integration surface for AI agents

Model Context Protocol is designed to connect agents to tools and data sources through a standard interface, which reduces integration friction but also concentrates risk. Any protocol that normalises access to many systems through one agent layer can increase blast radius if authentication, authorization, and logging are weak. The architectural question is not whether MCP is useful, but whether each connected tool has explicit policy, identity separation, and auditable approvals. Without those controls, the protocol can make it easier for agents to discover and use systems faster than security teams can classify them.

Practical implication: Require separate authorization boundaries and logging for each MCP-connected resource.

Threat narrative

Attacker objective: The attacker wants to abuse the agent’s trusted access path so legitimate automation becomes an execution channel for unauthorized actions.

1. Entry occurs when an AI agent is connected to databases, APIs, or development tools through weakly governed integrations.
2. Escalation follows when inherited permissions or overbroad tool scopes let the agent move from advice into execution across multiple systems.
3. Impact occurs when autonomous actions modify records, expose data, or trigger workflow changes without an explicit human approval step.

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

Agentic AI is now an NHI governance problem, not just an AI capability discussion. The moment an AI system can authenticate, query, and act across enterprise tools, it belongs in the same governance conversation as service accounts, API keys, and workload identities. Security teams that still treat agents as application features will miss the identity lifecycle, approval, and revocation issues that determine real exposure. The practical conclusion is simple: agents need owners, scopes, and reviews before they need more autonomy.

Ephemeral intelligence does not equal ephemeral privilege. An agent may behave dynamically, but the credentials and permissions behind it can be long-lived, inherited, or poorly observed. That creates identity blast radius, where a short-lived task can still affect durable systems if the access model is broad. The field needs to stop treating “temporary use” as a proxy for “low risk.” Practitioners should govern the privileges, not the marketing language around automation.

Memory makes access drift harder to see. Traditional identity reviews often assume entitlements are static enough to audit on a schedule. Agent memory and multi-step reasoning break that assumption because the same principal may change behavior as context accumulates. That creates a runtime governance gap: the access policy may still look valid while the actual actions are no longer aligned with intent. Teams should assume that auditability must move closer to execution time.

Model Context Protocol widens integration speed faster than most control frameworks can absorb. Standardised tool connections are attractive because they reduce engineering overhead, but they also make it easier to connect agents to systems without redesigning identity policy. That is where NHI governance becomes operational, not theoretical. The right response is not to block all agent integrations, but to require explicit trust boundaries, separate credentials, and detailed logging for every connected tool.

OWASP-style agentic risk management now needs to sit inside IAM decisions. Agent goal hijacking, tool misuse, and unauthorized data access are no longer edge cases when agents are embedded in production workflows. The security conversation should shift from “what can the model do” to “what can this identity reach, and who can constrain it.” Practitioners should use that lens to decide where autonomy is acceptable and where human approval must remain mandatory.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• That control gap is why OWASP NHI Top 10 is becoming a practical reference point for agent governance.

What this signals

Identity teams should expect agent counts to grow faster than governance maturity. The operational pattern is familiar: deployment scales first, then ownership, then policy. In this environment, the control objective is not to slow adoption, but to prevent unmanaged autonomy from becoming embedded in core workflows before entitlement reviews, approvals, and audit trails are in place.

Identity blast radius will become the metric that matters most. When an agent can reach multiple systems through one credential set, the size of the connected trust zone matters more than any single permission. That is why practitioners should measure connected scope, not just access count, and use that measurement to decide where agent autonomy can safely continue.

With 52% of companies able to track and audit the data their AI agents access, the remainder face a visibility problem that cannot be solved after deployment. Teams should prepare for stronger policy requirements around provenance, approval, and traceability, especially where agents touch sensitive data or regulated workflows.

For practitioners

• Inventory every deployed agent as an identity Assign an owner, business purpose, and expiration rule to each AI agent, then map its database, API, and file permissions as you would any other production principal.
• Restrict tool permissions by task scope Give each agent only the minimum read and write access needed for the workflow, and separate tools that can modify data from tools that only retrieve it.
• Require approval for high-impact actions Use human-in-the-loop gates for payments, data exports, user provisioning, code changes, and other actions that can create durable operational impact.
• Log agent prompts, tool calls, and outputs Capture the full execution trail so security teams can reconstruct what the agent saw, what it did, and which connected system it touched.
• Review MCP-connected integrations separately Treat each protocol-connected tool as a distinct trust boundary and validate authentication, authorization, and audit logging before enabling production use.

Key takeaways

• Agentic AI expands the non-human identity problem because execution authority now sits behind software that can plan and act.
• Governance gaps are already visible: autonomous behaviour, broad tool access, and weak auditability create practical exposure before most teams have formal controls.
• The right response is to inventory, scope, approve, and monitor agents as identities, not as isolated AI features.

Key terms

• Agentic AI: AI systems that can do more than generate content. They can plan, call tools, access data, and execute actions in connected environments, which means they create identity, authorization, and accountability issues that look much closer to software principals than to chat interfaces.
• Non-Human Identity: A machine, workload, service account, token, certificate, or agent that authenticates and acts inside an environment without a human user at the keyboard. In practice, NHIs need lifecycle management, access boundaries, and auditability because they can create real operational impact.
• Identity Blast Radius: The amount of damage a single identity can cause if it is compromised or mis-scoped. For AI agents, blast radius grows when one principal can reach multiple tools, datasets, or write paths, making narrow permissions and separate trust boundaries essential.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.

Deepen your knowledge

Agentic AI governance and non-human identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is beginning to classify autonomous agents as production identities, this is a practical place to start.

This post draws on content published by Noma Security: The evolving AI landscape and the shift from models to agents. Read the original.