As AI systems begin to act across tools, models, sessions, and vendors, identity becomes the control surface leaders can still govern.
Related Big Read: When the algorithm holds the key: governing AI agents in the security stack
AI-generated attacks are becoming faster and more adaptive. At the same time, enterprise AI systems are starting to operate across multiple models, vendors, sessions, tools, and compliance boundaries. A human user may initiate the workflow, but the action may be carried out by a model, an agent, a plugin, a service account, or a chain of delegated permissions.
If that actor cannot be named, scoped, monitored, and revoked, it should not be trusted with meaningful authority.
That is the early Agent Identity Governance problem.
What the evidence to date shows
Two stories this September illustrate the necessity of shifting to agent identity as a control boundary.
Microsoft’s decision to add Anthropic’s Claude models to Copilot showed enterprise workflows beginning to span multiple models and vendors, making the model behind an action part of the trust boundary.
A large credential and session-cookie exposure showed the other side of the problem: identity controls are already fragile when access depends on tokens that can be stolen or reused.
Taken together, these examples point to a common shift. The enterprise is adding more non-human actors to systems whose identity controls were built around people, accounts, and applications.
Why human-readable security starts to fail
Traditional security governance works best when the object of control is stable enough to review.
A user has a role. An application has an owner. A server has a configuration. A supplier has a contract. A piece of malware has code that can be analysed and compared with known patterns.
Agentic systems erode that assumption.
The model can generate action at runtime. The workflow can call tools. The choice of model can change the compliance boundary. The agent may inherit a human user’s permissions. A session token may give access that MFA no longer protects. A vendor integration may shift data to a different processing environment without appearing to the user like a new application.
The security question moves from “what is this thing?” to “what is this thing allowed to do right now?”
That question cannot be answered without identity.
The framework
Agent Identity Governance starts with a simple premise:
Every non-human actor that can access, decide, trigger, approve, export, or modify enterprise data needs to be governed as an identity.
Not because agents are people, but because authority has to be attached to something.
Use this framework before agentic workflows are given meaningful access or execution rights.
Work through the six controls below to test whether the organisation can name the actor, separate its authority, scope its work, monitor its behaviour, understand the model boundary, and revoke access precisely.
01
1. Name the actor
An agent cannot be governed if it exists only as a feature inside someone else’s workflow.
At minimum, an organisation needs a registry of deployed agents, copilots, bots, automations, and model-connected workflows. The registry should identify the owning team, the human accountable for the agent, the systems it can access, the models it uses, the deployment date, and how and when it is reviewed.
The test is simple: can the organisation produce a list of deployed agents within 24 hours?
If not, there is no functional inventory.
02
The easiest way to deploy an agent is to let it inherit a user’s permissions.
But this is the wrong way to govern it.
Human permissions are usually broader than their workflows require. They include exceptions, historic access, collaboration sprawl, and role drift. If an agent inherits that authority, the organisation has not created a controlled automation. It has created a faster version of a human account with less judgement and more reach.
Agents need their own credentials or service principals, scoped to the workflow they perform.
03
3. Scope the work, not the convenience
Least privilege becomes even more important when execution is delegated.
The organisation should define what the agent needs to read, write, call, approve, and trigger. Everything else should be excluded by default. Long-lived tokens should be avoided or tightly rotated. Agents should not be able to self-escalate or invoke other agents with broader authority unless that path is explicitly designed and monitored.
This is where agent governance stops being policy language and becomes architecture.
04
4. Watch behaviour inside valid sessions
Authentication on its own is not enough.
An agent can behave badly while using a valid identity. A compromised token, a prompt-injected workflow, an unexpected model route, or a vendor-side change may not result in a failed login. It may produce a valid sequence of actions that sits outside the intended pattern.
Monitoring must include expected systems accessed, typical action volumes, operating hours, data types handled, external calls, and unusual workflow chains.
The first alert should not be a user report of an access problem.
05
5. Detect the compliance boundary
The Microsoft and Claude/Copilot combination illustrates the problem in practice: the host application is no longer enough to define the trust boundary.
Two requests can appear to belong to the same enterprise platform while being processed by different models, under different terms, and with different data-handling assumptions.
That means DLP, logging, and governance rules need to understand which model processed the request and which application was used.
06
6. Revoke with precision
Revocation is the control that proves the identity model is real.
If an agent behaves unexpectedly, can the organisation pause that agent without disabling an entire business platform? Can it revoke the token, narrow the scope, rotate credentials, and preserve the logs? Can it tell which workflows were touched and which data could be reached?
If not, the agent’s authority is not really bounded.
It is merely hoped to be bounded.
Control rule
If the organisation cannot name the agent, separate its authority, scope its work, observe its behaviour, detect the model boundary, and revoke access precisely, the workflow should not proceed with meaningful enterprise authority.
What leaders should be asking before approving agentic workflows
- Which non-human actors can currently access enterprise systems?
- Which of them have their own identities rather than inherited human credentials?
- Who owns each one?
- What can each one read, write, export, approve, or trigger?
- Which model processes the request, and under what compliance framework?
- What behaviour would be anomalous for each agent?
- How quickly can access be revoked without breaking unrelated systems?
These are not technical curiosities. Instead, they are the minimum questions that make delegated machine authority governable.
Why this matters to the board
Boards do not need to approve every agent deployment.
They do need assurance that the organisation is not creating invisible authority. As AI moves from interface to action, unmanaged agents can introduce operational risk that governance structures are not yet built to detect. They may move data, initiate workflows, contact systems, invoke tools, or operate across vendor boundaries while still being treated as a productivity feature.
That is too thin a control model.
The practical board-level ask is straightforward: before agentic workflows scale, management should be able to evidence inventory, ownership, permission scoping, monitoring, model-route visibility, and revocation.
If those controls are absent, the organisation is not experimenting with AI.
It is delegating authority without a ledger.
