An agent might retrieve information, update a record, initiate a workflow or interact with another application without a person approving every individual step.
The business opportunity is significant. So is the governance question.
Before approving an agent that can act on behalf of employees, customers or the organisation itself, there are several questions that should have clear answers.
Key Takeaways
- Agentic AI introduces new enterprise actors that require explicit ownership, authority and accountability.
- Boards should focus less on the underlying model and more on what an agent can access and do.
- Delegated authority, least privilege, lifecycle management and auditability are central to responsible deployment.
- Organisations need to be able to demonstrate not only that an agent was authorised, but that the specific action it took was authorised in context.
1. What exactly is the agent allowed to do?
An answer such as “it has access to the CRM” is not enough.
Can it read customer records? Modify them? Create new records? Trigger a workflow? Export information? Call another service?
The more autonomous the agent, the more important it becomes to define authority at the level of actions and resources rather than simply applications.
This is an extension of a principle identity teams already know well: least privilege.
The difference is that an agent can potentially exercise its permissions at machine speed and across a chain of systems.
The question for executives is therefore not simply whether an agent has access.
It is whether that access is appropriate for the task it has been given.
2. Who owns it?
Every enterprise agent should have an accountable owner.
That does not mean someone needs to manually approve every action. It means there is a person or function responsible for the agent's purpose, access and lifecycle.
This becomes especially important as organisations accumulate agents created by different teams.
An agent without a clear owner is difficult to review, difficult to retire and difficult to investigate when something goes wrong.
Current approaches to agent identity therefore treat agents as governed non-human identities with ownership, lifecycle controls and accountability rather than as anonymous software components.
3. Whose authority is the agent using?
This is perhaps the most important question.
Many agentic workflows begin with a legitimate human request. The employee asks an agent to perform a task, and the agent then interacts with enterprise systems.
The security model should preserve that relationship.
The agent should not simply inherit the employee's credentials or receive an unrestricted copy of the employee's permissions.
Instead, the organisation should establish what authority has been delegated to the agent and constrain that authority to the task.
This is the difference between delegation and impersonation.
Authenticated delegation allows an organisation to preserve the relationship between the human principal, the agent and the action. It also provides a basis for revoking or narrowing that authority when circumstances change.
4. What happens when the agent changes?
An agent's initial configuration is not necessarily its final configuration.
Its owner may change. New tools may be connected. Its responsibilities may expand. A pilot may become a production service.
Identity governance has long dealt with this problem for human and non-human identities.
Access needs to be reviewed as circumstances change.
The same principle applies here.
An organisation should know:
- when an agent was created;
- who owns it;
- what it is intended to do;
- what resources it can access;
- what authority has been delegated;
- when that access should expire or be reviewed; and
- how the agent can be disabled or retired.
This lifecycle perspective is essential if organisations are going to move from a handful of controlled pilots to an environment containing hundreds or thousands of agents.
5. Can we see what it actually did?
Auditability becomes particularly important when an agent operates autonomously.
After an incident, a record showing only that an API was called may not provide enough context.
Security and compliance teams may need to establish:
Which agent acted?
Who was the agent acting for?
What authority had been delegated?
What resource was requested?
What policy decision allowed the action?
Was human approval required?
These details form the chain of accountability.
Without that chain, organisations can find themselves with an automated system that technically worked as designed but cannot explain why a particular outcome occurred.
6. What happens when the risk changes?
Not every action deserves the same level of autonomy.
Reading a public document is different from changing a customer's account details. Updating an internal record is different from initiating a financial transaction.
This is where context matters.
Organisations should consider whether higher-risk actions require additional verification, narrower permissions or human approval.
Runtime identity approaches this by evaluating identity, delegated authority and context when an action occurs rather than relying solely on permissions established when the agent was initially configured.
For boards, the underlying question is straightforward:
Does the organisation have a mechanism for distinguishing acceptable autonomy from unacceptable autonomy?
The board does not need to design the architecture
Boards should not be deciding which identity protocol an agent uses or how a particular API is configured.
They should be asking whether management has established a control environment that is proportionate to the agent's authority and potential impact.
That means understanding the organisation's ability to identify agents, establish ownership, constrain authority, monitor activity and intervene when necessary.
The goal is not to create a new approval process around every AI experiment.
It is to ensure that experimentation does not quietly become enterprise authority without enterprise governance.
As AI agents become more capable, the question for boards is ultimately one of accountability:
Can we explain who or what acted, under whose authority, and why that action was permitted?
If the answer is yes, the organisation has a foundation for scaling AI with confidence.
If the answer is no, the governance problem is already larger than the technology problem.
From Breach to Board-Ready: A Governance Playbook for Agentic AI
Discover how identity-first governance can help organisations secure AI agents, enforce least privilege and strengthen enterprise oversight.
