Introduction: agents are shipping faster than guardrails
Agentic AI — systems capable of autonomous reasoning, planning, and multi-step execution without continuous human instruction — crossed the production threshold in 2026. From cloud infrastructure management to customer service workflows to SOC triage, agents are now performing work that was previously human-mediated.
The problem is not capability. The problem is governance. Most enterprises deploying agents in 2026 are doing so faster than they can audit, control, or even enumerate them. The gap between deployment velocity and governance maturity is creating a new category of enterprise risk that traditional security and compliance frameworks were not designed to address.
This article covers the specific governance, identity, and orchestration challenges that emerge when agentic AI moves from demo to production — and the architectural patterns that address them.
The control plane gap
The first and most common governance failure in agentic AI deployments is fragmented management. Agents are deployed by different teams — engineering, security, customer success, operations — using different frameworks, with different access patterns, and without centralised visibility.
What a control plane provides:
A centralised control plane for agentic AI is not a dashboard. It is an enforcement layer that provides:
- Agent registry: a canonical list of every agent in production, its purpose, its owner, and its current permissions.
- Policy enforcement: runtime policies that govern what agents can access, what actions they can take, and under what conditions human approval is required.
- Kill switches: the ability to immediately disable any agent or class of agents without requiring the deploying team's involvement.
- Audit trails: immutable, timestamped records of every action every agent takes — including the reasoning chain that led to the action.
- Cost boundaries: per-agent and per-workflow token and compute budgets with hard limits, not just alerts.
Without a control plane, organisations cannot answer basic questions: "How many agents do we have in production?" "What can they access?" "Who approved their deployment?" "What did they do yesterday?"
Identity and privilege: the IAM problem agents create
Traditional IAM was designed for humans. Humans authenticate, receive role-based access, and perform actions within their granted scope. The access model assumes a human decision-maker behind every action.
Agents break this model in three specific ways:
1. Privilege drift
Agents are typically deployed with the permissions their initial use case requires. Over time, as the agent's responsibilities expand or as it is copied and modified for adjacent use cases, permissions accumulate. Unlike human accounts that are subject to periodic access reviews, agent permissions often escape the review cycle entirely.
The result is agents with broad, unnecessary access that was appropriate for an earlier version of their workflow but is now an attack surface.
Mitigation: implement just-in-time (JIT) permission grants with automatic expiration. Every agent permission should have a TTL (time-to-live). Permissions that are not actively used should expire and require re-approval.
2. Shadow agents
Shadow agents are autonomous systems operating outside the security governance perimeter. They are typically created by individual teams using personal API keys, deployed in personal cloud accounts, or running as background processes on developer machines.
Shadow agents are the agentic AI equivalent of shadow IT — but with the ability to take actions, not just store data. A shadow agent with access to production APIs can modify infrastructure, exfiltrate data, or interact with customers without any organisational visibility.
Mitigation: enforce agent deployment exclusively through the control plane. API key issuance for agent use cases should require control plane registration. Monitor for anomalous API usage patterns that suggest unregistered agents.
3. Broken delegation chains
In multi-agent architectures, agents delegate tasks to other agents. Each delegation creates a trust boundary. If Agent A delegates to Agent B, and Agent B has been compromised or misconfigured, Agent A's permissions are effectively extended to the compromised agent.
Delegation chains without explicit trust verification create implicit privilege escalation paths. An attacker who compromises a low-privilege agent can traverse delegation chains to reach high-privilege operations.
Mitigation: implement explicit trust verification at every delegation boundary. Each agent-to-agent delegation should require cryptographic identity verification, scope validation, and audit logging. No implicit trust between agents.
Orchestration complexity at scale
Single-agent deployments are relatively straightforward to govern. Multi-agent architectures — where agents coordinate, delegate, and communicate — introduce complexity that scales non-linearly.
Race conditions and coordination failures
When multiple agents operate on shared resources — a database, a customer record, a cloud infrastructure component — race conditions emerge. Agent A reads a value, Agent B modifies it, Agent A acts on the stale value. In traditional software, these are solved with locks and transactions. In agentic systems, where agents may be reasoning about the world over seconds or minutes rather than milliseconds, traditional concurrency primitives are insufficient.
Cascading failures
When Agent A depends on Agent B's output to make a decision, and Agent B fails or produces an incorrect result, Agent A's subsequent actions propagate the error. In multi-agent chains, a single point of failure can cascade through the entire workflow before any monitoring system detects the issue.
Architectural response: implement circuit breakers at agent boundaries. If Agent B's error rate exceeds a threshold, Agent A should gracefully degrade — either queuing the task for human review or falling back to a simpler, deterministic process.
Unreproducible errors
Agentic workflows are non-deterministic by nature. The same input can produce different reasoning chains and different actions. This makes debugging production incidents significantly harder than debugging traditional software — the error may not reproduce in staging, because the agent's reasoning path was different.
Architectural response: log the full reasoning chain — not just inputs and outputs — for every agent action. Implement replay capabilities that can re-execute a specific reasoning chain with the same context to reproduce failures.
Cost governance: when agents spend money
Agentic workflows have variable execution paths. A simple query might resolve in one LLM call; a complex one might trigger dozens of calls, tool invocations, and sub-agent delegations. Without cost governance, a single poorly-scoped agent can generate significant compute bills before anyone notices.
Cost control patterns:
- Per-agent token budgets: hard limits on the number of tokens an agent can consume per task, per hour, and per day.
- Per-workflow cost caps: budget limits on end-to-end workflow execution, with automatic termination when the cap is reached.
- Cost anomaly detection: alert when an agent's per-task cost deviates significantly from its historical baseline.
- Cost attribution: map every LLM call, tool invocation, and compute unit to a specific agent, workflow, and business function for FinOps reporting.
Human-in-the-loop: where to draw the line
Not every agent action requires human approval. But some actions — those that are irreversible, customer-visible, legally significant, or financially material — must require explicit human authorisation before execution.
Actions that should always require human approval:
- Customer-visible communications (emails, messages, notifications)
- Financial transactions above a defined threshold
- Infrastructure changes that affect production availability
- Data deletion or modification in systems of record
- Escalation actions that change severity levels or trigger incident response
Actions that can be safely automated:
- Data retrieval and summarisation
- Internal routing and triage
- Alert enrichment and context gathering
- Report generation and formatting
- Monitoring and anomaly detection
The boundary between automated and human-approved actions should be encoded in the control plane policy — not in individual agent configurations and not in tribal knowledge.
Key takeaways
- Agentic AI governance requires a centralised control plane — agent registry, policy enforcement, kill switches, audit trails, and cost boundaries — not scattered team-level management.
- Traditional IAM fails for agents: implement JIT permissions with TTLs, enforce control plane registration to prevent shadow agents, and verify trust at every delegation boundary.
- Multi-agent orchestration introduces non-linear complexity: race conditions, cascading failures, and unreproducible errors require circuit breakers, reasoning chain logging, and replay capabilities.
- Cost governance must include per-agent budgets, per-workflow caps, anomaly detection, and cost attribution to business functions.
- Human-in-the-loop requirements should be encoded in control plane policy, covering irreversible, customer-visible, and financially material actions.
- The organisations succeeding with agentic AI in 2026 adopted governance-first architectures — not governance as a retrofit.
Frequently asked questions
What is a control plane for agentic AI? A centralised enforcement layer that provides an agent registry, runtime policy enforcement, kill switches, immutable audit trails, and cost boundaries. It answers: how many agents are in production, what can they access, who approved them, and what are they doing right now.
How is agentic AI identity different from traditional IAM? Traditional IAM assumes a human decision-maker. Agents need scoped, time-bound, auditable identities with just-in-time permission grants, automatic expiration, and cryptographic trust verification at delegation boundaries — patterns traditional role-based access was not designed for.
What are shadow agents and why are they dangerous? Shadow agents are autonomous systems operating outside organisational governance — deployed with personal API keys, running on developer machines, or created by teams without control plane registration. They can take actions in production without any visibility or oversight.
Can AiRAT help with agentic AI governance? Yes — we design governance architectures, control plane implementations, and observability stacks for agentic AI deployments. Book a strategy session to discuss your current agent landscape and governance requirements.
Sources: NIST AI Risk Management Framework, OWASP Top 10 for LLM Applications, verified 10 August 2026.
Related: Governed LLM APIs: rate limits and tenancy · Observability for AI systems · LLM evaluation frameworks · AI & platform services
