Agent identity is the practice of giving every AI agent its own recorded identity, owner and access level, so you can answer who or what did something and what it was allowed to touch. For a board, it is the same control you already expect for employees, applied to software that now acts on its own.
Why would a board care about this at all?
Boards care about three things: loss, liability and surprise. Agents touch all three. An AI agent that can open pull requests, read tickets or call internal tools is acting with real credentials. If nobody can list those agents, nobody can say what a bad day looks like.
The useful framing is not "AI risk" in the abstract. It is an inventory and permissions question your auditors already understand. We have a list of staff and what each can reach. Do we have the same list for agents?
The UK National Cyber Security Centre publishes a toolkit that helps boards ask better cyber questions of their teams. It is a good model for the tone: plain questions, no jargon, and a request for evidence instead of reassurance.
What is the risk in one minute?
Use three sentences.
First, agents are given credentials such as API keys and tokens. Second, those credentials are often broader than the task needs, shared between agents, or never expire. Third, if an agent is tricked or misbehaves, it acts with everything it was given.
None of this is speculation. OWASP lists "Excessive Agency" as a risk for LLM applications and names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its Non-Human Identities Top 10 lists improper offboarding, secret leakage, overprivileged identities and long-lived secrets among the main risks for machine credentials in general.
Say it that way. You are not asking the board to fear a new technology. You are showing that known identity failures now apply to a new kind of actor.
What does the CFO need to hear?
A CFO wants to know what it costs and what it replaces. Be honest on both.
Cost drivers are mostly people and process, not licences: someone has to own the agent inventory, approve access, and review exceptions. Tooling can reduce that work, but the first deliverable is a list and an owner for each entry. We are not quoting prices here, because they vary and you should get quotes.
What it replaces: ad hoc approvals in chat, spreadsheets of keys that nobody trusts, and the unplanned hours spent after an incident working out which agent held which token.
The CFO's useful question is: "If an agent causes an incident, what is the maximum it could have touched?" If the answer is "we would have to investigate", that is the gap you are funding.
What should the board see each quarter?
Keep it to a few numbers that you can defend, and avoid vanity counts.
- How many agents are in production, and how many have a named human owner.
- How many hold access that has not been reviewed in the period you set by policy.
- How many credentials are long lived versus short lived.
- How many agent actions required a human approval, and how many were declined.
A rising count of agents is not good or bad on its own. A rising count of agents with no owner is bad.
What do you ask the board for?
Ask for a decision, not applause. Three decisions are enough:
- Agree that no agent goes to production without a named owner and a defined access scope.
- Agree that high impact actions, such as deleting data or changing production, need a human approval step.
- Fund a first pass at discovery, so the inventory exists before the policy is enforced.
What to do
- Write a one page definition: what counts as an agent in your company, and who owns the list.
- Build the first inventory by hand if you must. Include the agent, its owner, the systems it can reach and the credential type.
- Mark every agent with write or delete access. These get reviewed first.
- Replace long lived keys with short lived ones where the platform allows it.
- Set an approval rule for destructive actions and write down who approves.
- Report the four numbers above each quarter, with the trend and the exceptions.
- Rehearse one scenario aloud: an agent is found acting outside its scope. Who is called, and what is switched off?
Where Safeguard fits
Safeguard's agent identity capability tracks which AI agents hold what access, at what level, and its guardrails and policies can enforce limits at build, CI and release. That gives the inventory and the approval rule in the steps above a place to live. It covers the application and software delivery side. It does not replace your wider identity provider or your endpoint and network tooling.
Quick check
Is agent identity just service account management?
It overlaps, but agents add two differences: they decide what to do at run time, and they can be steered by the content they read. So scope and approval rules matter more than they do for a fixed batch job.
What is the first thing to show a board?
A simple inventory with an owner for each agent and a count of agents with write access. It turns an abstract risk into a list people can act on.
Sources
- OWASP LLM Top 10, Excessive Agency
- OWASP Non-Human Identities Top 10
- OWASP Top 10 for Agentic Applications for 2026
- NCSC Cyber Security Toolkit for Boards
Last reviewed: 18 October 2026.
