AI agents in infrastructure need operator-grade identity controls

At a glance

What this is: This is an independent analysis of AI agents moving into infrastructure operations, and its key finding is that once AI can act, it must be governed as an operator rather than a passive tool.

Why it matters: It matters because IAM, PAM, and governance teams now have to decide how to bound AI-driven actions across NHI, autonomous, and human control models before those actions reach production systems.

👉 Read Orca Security's analysis of AI agents as operators in infrastructure

Context

AI agents are moving from answering questions to taking actions inside real systems, which changes the identity model from access to operation. Once an AI system can write code, call APIs, and trigger workflows, the core problem becomes who or what is authorised to act, not just who can log in.

Existing control models assume a clear separation between instructions and data, and that assumption weakens when prompts, context, and untrusted inputs all influence runtime behaviour. For identity teams, the result is a governance gap spanning workload identity, privileged access, and emerging agent controls, especially where production systems are directly exposed.

The practical question is no longer whether AI can improve throughput. It is whether the organisation can place boundaries around AI action, preserve accountability, and keep sensitive tasks inside observable and reviewable control paths.

Key questions

Q: How should security teams govern AI agents that can act inside production systems?

A: Security teams should govern them as operator identities with bounded authority, not as passive tools. Define the systems they may touch, separate read and write permissions, and require approval for sensitive state-changing actions. The important question is not whether the agent is useful, but whether its action path is controlled, observable, and reviewable.

Q: Why do AI agents change traditional IAM assumptions?

A: They change IAM assumptions because identity is no longer only about authentication and access. When an AI system can initiate actions, identity governance must address what it may do, when it may do it, and how those actions are verified. Static permission models are weaker when runtime behaviour can vary with context.

Q: What do security teams get wrong about prompt injection?

A: Teams often treat prompt injection as a content problem, when it is also an execution problem. If untrusted text can influence tool use or workflow decisions, the issue becomes a control boundary failure. The safest response is to prevent untrusted material from directly shaping state-changing actions.

Q: How can organisations tell whether an AI operator is staying within scope?

A: They should look for durable evidence of prompts, tool calls, sensitive actions, and approvals. If the organisation cannot reconstruct what the system did and why, scope control is not working. Auditability is the difference between a governed operator and an unaccountable one.

Technical breakdown

Why AI agents become operators inside infrastructure

An AI agent crosses a security boundary when it moves from generating content to initiating actions in systems that matter. That includes code generation that is executed, API calls that change state, and workflow steps that affect customers or infrastructure. At that point, the relevant identity question is not whether the model is useful, but what permissions and approvals govern the action path. Security teams should treat the agent as an executing identity with bounded authority, not as a passive interface layer.

Practical implication: define the action surfaces an AI system may touch before it is allowed to touch production.

How prompt injection blurs control flow and data flow

Traditional secure design separates instructions from data so that untrusted content cannot redirect execution. Large language models weaken that separation because prompt content, retrieved context, and user input share the same decision space. That creates a path where malicious or misleading content can alter what the agent believes it should do. The control failure is not just bad output. It is that the system cannot always distinguish trusted policy from untrusted influence at runtime.

Practical implication: isolate untrusted inputs from agent instructions and require review for any action that changes state.

Why observable and auditable behaviour becomes mandatory

Once AI acts inside production workflows, the important control is not only what it can do, but whether the organisation can reconstruct what it did and why. Observability means the system leaves a trace of inputs, decisions, tool use, and outcomes. Auditability means those traces are retained in a form that supports review and accountability. Without both, teams cannot tell whether the agent followed policy, exceeded scope, or acted on corrupted context.

Practical implication: instrument agent activity with durable logs, decision records, and sensitive-action checkpoints.

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 agents are becoming operator identities, not just application features. The security model changes the moment a system can write code, call APIs, or alter workflows in live environments. That shifts the governance burden from content safety to operational authority. Practitioners should classify the agent by the actions it can take, not the interface it uses.

The control separation between instructions and data is the fault line this category exposes. Traditional governance assumes policy is stable and inputs are subordinate to it. Prompt injection shows that assumption can fail when untrusted content shares the same runtime context as instructions. The implication is that identity and policy enforcement must account for influence over action, not only access to data.

Defined permissions and human verification are operator controls, not optional safety extras. Once AI can affect production systems, it needs the same boundary discipline applied to domain admins, service identities, and other high-impact operators. The organisation is not deciding whether to trust a chatbot. It is deciding whether to let an executing identity act without containment. Practitioners should govern AI action paths with the same seriousness they apply to privileged access.

Observable, auditable behaviour is the named concept that should anchor this category. If an AI system cannot be reconstructed after the fact, then it is already outside mature identity governance. This is not a tooling preference. It is a failure of accountability design. The practical conclusion is that AI operators must leave reviewable evidence for every sensitive action they take.

Autonomous-style behaviour sharpens the governance question even when the system is not fully autonomous. The more runtime discretion an AI system has, the less useful static access assumptions become. That does not make every AI tool autonomous, but it does mean existing IAM and PAM patterns start to lose explanatory power. Practitioners should re-evaluate whether their controls assume a human-paced operator behind every action.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• From our research: Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to the same survey.
• For a deeper control view: Read OWASP NHI Top 10 for the agentic risk patterns that shape runtime governance.

What this signals

Observable, auditable behaviour is becoming the dividing line between experimental AI and governed AI. Once an agent can trigger real actions, security teams need evidence trails for prompts, tools, approvals, and outcomes, or they will be unable to prove scope control after the fact.

The governance gap is already structural: with 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, identity programmes need to prepare for more runtime discretion and less human pacing. That makes action-boundary design, not just access provisioning, the programme priority.

For teams aligning controls to external frameworks, the governance question maps cleanly to NIST Cybersecurity Framework 2.0 and the agentic risk patterns covered in OWASP NHI Top 10. The practical signal is simple: if you cannot explain an AI action chain, you do not yet control it.

For practitioners

• Classify AI systems by action authority Map each agent to the exact systems, APIs, and workflows it can affect. Separate read-only support from write-capable operations, and require different approval paths for each.
• Gate sensitive actions with human verification Require a human checkpoint before any AI-driven change that can impact customers, infrastructure, or security settings. Keep the checkpoint specific to the action, not the session.
• Instrument agent behaviour for auditability Log prompts, tool calls, outputs, and state-changing actions in a durable format that security teams can review after the fact. Preserve enough context to explain why the action happened.
• Limit untrusted input influence on execution Separate retrieved content, user text, and policy instructions where possible, and block direct promotion of untrusted material into decision-making context. Treat prompt injection as a control boundary problem.

Key takeaways

• AI agents stop being simple tools once they can act on infrastructure, because they then require operator-grade identity boundaries.
• The weak point is the control boundary between instructions and data, where prompt injection can redirect real actions.
• Governance now depends on bounded permissions, human verification for sensitive changes, and durable audit trails for every meaningful agent action.

Key terms

• AI Operator Identity: An AI operator identity is a system identity that can initiate actions in infrastructure, applications, or workflows. It is more than a chatbot session because it can change state, call tools, and trigger outcomes. Governance has to cover authority, traceability, and approval boundaries, not just authentication.
• Prompt Injection: Prompt injection is the use of malicious or misleading content to influence how an AI system behaves at runtime. The security issue is not only incorrect output. It is that untrusted input can alter tool use, policy interpretation, or execution paths if the system does not separate instruction from data.
• Observable and Auditable Behaviour: Observable and auditable behaviour means an AI system leaves reviewable evidence of what it was asked, what tools it used, what actions it took, and what outcomes followed. In identity governance terms, this is the minimum evidence needed to prove scope, accountability, and policy adherence after the fact.
• Control Boundary: A control boundary is the line that keeps policy, instruction, and permission decisions separate from untrusted input. In AI systems, that boundary is weaker because context can shape execution. Strong governance depends on preserving that separation before the system is allowed to affect production state.

Deepen your knowledge

AI agent governance and operator-grade identity boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are defining controls for systems that can act inside production workflows, it is worth exploring.

This post draws on content published by Orca Security: The Tool Becomes the Operator. Read the original.