Your
Trusted
Get Fully AWS Funded
Cloud Migration
Cloud Migration
An agent acts across systems and tools on behalf of a user or workflow. A dedicated identity makes its permissions, actions and audit trail distinguishable from those of people and other workloads.
It can, but the organisation loses clarity over which actions came from the agent and risks inheriting permissions that were designed for a different role. Scoped, dedicated and short-lived credentials create a clearer control boundary.
No. Controls should reflect the agent’s authority, data sensitivity and access to downstream systems. Read-only use cases still need clear data boundaries, user authentication and logs.
Review the agent’s owner, authorised users, data sources, tool permissions, approval points, logging, credential lifecycle and incident-response path. These checks should be part of the delivery workflow, rather than a review added after the agent has already accumulated access.
An AI agent that prepares an account brief may read CRM records, query a data warehouse, call internal APIs and write an update back into a workflow. Each connection is useful. Each one also raises a practical question: whose authority is the agent using, how far does that authority reach and can the business reconstruct an action after something goes wrong?
That is why the conversation around agents is moving beyond model choice. Production agents introduce a new class of identity architecture. They act across systems, often at machine speed, and they make access decisions operational.
The data already shows the scale of the shift. 83% of organisations say they need infrastructure upgrades to support production-grade agentic AI. 79% see security, governance or MLOps as the most significant challenge to scaling inference.
An agent can read a document. It can also trigger a refund, create a ticket, change a record, initiate a deployment or pass data to another system. The issue is rarely one permission in isolation. It is the path created when several permissions, tools and identities are combined in one workflow.
That wider surface is showing up in security data. 87% of experts identify AI-related vulnerabilities as the fastest-growing cyber risk. The share of organisations assessing the security of AI tools nearly doubled, from 37% to 64%. Progress is real, although roughly one third still lacks a process to validate AI security before deployment.
This is where an agent differs from a conventional application integration. A conventional integration usually follows a stable, narrow path. An agent is asked to interpret context, select tools and work through a sequence of actions. The access model has to account for that wider range of execution paths.
85% of organisations use AI agents in production environments, and 68% cannot clearly distinguish actions carried out by a human from those carried out by an agent.
That figure has a direct business consequence. When a customer record changes, a sensitive file is retrieved or an approval workflow starts, the organisation needs to know which identity initiated the event, which data was used and which permissions allowed the action. Auditability, incident response and regulatory accountability all depend on that answer.
The same survey exposes the access problem behind the visibility gap. 74% say agents often receive more access than they need. 79% believe they create new access pathways that are difficult to monitor. Many agents borrow existing human permissions, shared service accounts or generic workload identities because these are the paths already available inside the organisation.
The result is a familiar pattern for cloud teams. Convenience wins during an early build. The temporary permission becomes part of production. The team later discovers that nobody can clearly explain the boundaries.
A production agent usually involves at least three separate identity relationships.
User to agent. Who is allowed to invoke the agent, and with which role, account or business context?
Agent to tool. Which APIs, databases, queues, SaaS applications or cloud services can the agent call while it carries out a task?
Tool to downstream system. What identity is used when that tool reaches a payment system, a deployment pipeline, a customer database or another internal service?
Separate authentication points are needed for the user invoking the agent, the agent calling a tool and the tool reaching downstream systems. A user’s permission to ask for an action should not automatically become an agent’s broad, persistent authority to perform every related action.
A practical review should make four decisions visible:
Many teams already have these elements somewhere in their cloud estate. The difficulty is bringing them together in the runtime path where the agent actually operates.
A policy can state that agents should use least privilege. A production system needs a way to enforce it, observe it and revoke it.
Only 22% report that access frameworks are applied very consistently to AI agents. Just 21% maintain a real-time registry or inventory of their agents. These are basic operational capabilities, yet they remain uneven while agent deployments accelerate.
Nearly three quarters of organisations are giving agentic AI access to their data and processes, while 20% have a tested incident-response plan for an AI failure. The gap is important because an agent failure may involve more than a bad answer. It can involve a permission decision, a tool call, a data transfer and an action in a live business process.
Good governance therefore has to operate at runtime. It needs discovery, scoped credentials, approval routes for high-impact actions, audit trails and a practical way to stop or contain an agent when its behaviour changes.
This does not mean every internal assistant needs a complex enterprise identity platform on day one. A read-only agent confined to a small, approved knowledge base has a different risk profile from an agent that changes production records or calls financial systems.
The design should follow the authority granted to the agent.
This approach gives teams space to learn without treating every experiment as a production service. It also prevents a useful pilot from quietly accumulating permissions until it becomes an unmanaged operational dependency.
The agent itself is only one component. It sits between people, data, tools, cloud infrastructure and business processes. The operational work lives in those connections.
A production-ready AI capability layer makes those connections governable. It gives the organisation a way to separate identities, apply policies close to the action, observe agent behaviour and decide where human judgment remains necessary. That is the foundation that lets an AI workflow become part of a business process without becoming a blind spot.
The question for leadership is increasingly practical: if an agent takes an action in a customer, financial or production system tomorrow, can the organisation explain who authorised it, what it accessed, why it acted and how it can be stopped?