Agentic AI Identity Risk: A Board & CISO Briefing

AI agents are being given the keys to business systems faster than organisations are deciding who holds those keys. Agents now read and send email, change records, write and deploy code, and act on behalf of employees and customers. Their credentials decide how much damage follows when an agent errs or is manipulated. It is for directors, executives and CISOs. It covers the risk in business terms, the questions to ask, what good looks like, where to invest, metrics and a 90-day plan. Wider AI security risks are covered in our companion Board Briefing on AI security.

The risk in one paragraph

Every AI agent that takes action is a non-human identity: software holding access to systems and data. Unlike traditional automation, agents decide their own next steps and can be redirected by content they read, such as an email, a web page or a document. If an agent holds broad access, a single malicious instruction or an honest error can become a data breach, a fraudulent transaction or a production outage, carried out with legitimate credentials. The model's intelligence does not set the size of the damage; the agent's access does. That is why the protection has to come from identity controls (who the agent is, what it may touch, for how long, and who answers for it) rather than from instructions telling the agent to behave. The OWASP Top 10 for Agentic Applications puts it plainly: without "a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible."

Risk	What it means for the business	OWASP reference	Main control
Agent hijack	Content the agent reads changes its goal, and it uses its real access to act for the attacker	ASI01: Agent Goal Hijack	Limit what each agent can reach; treat external content as untrusted
Over-privileged agents	An agent holds far more access than its task needs, so any failure has a large blast radius	ASI03: Identity and Privilege Abuse; NHI5:2025 Overprivileged NHI	Own identity per agent, least privilege, short-lived credentials
Misuse of tools	An agent uses tools it was legitimately given in harmful ways, such as deleting data	ASI02: Tool Misuse and Exploitation	Human approval for irreversible actions, enforced by the platform
Third-party agents and integrations	A supplier's agent, plug-in or AI app holding our tokens is compromised	ASI04: Agentic Supply Chain Vulnerabilities	Supplier assessment, scoped and expiring grants
Agents borrowing human access	Agents run on an employee's login or shared keys, so actions cannot be told apart or revoked cleanly	NHI10:2025 Human Use of NHI	Dedicated agent identities with a named owner
Forgotten agents and keys	Agents and credentials outlive the projects that created them	NHI1:2025 Improper Offboarding; NHI7:2025 Long-Lived Secrets	Inventory, ownership, expiry and decommissioning
Rogue or runaway agents	An agent keeps acting outside its purpose and nobody can stop it quickly	ASI10: Rogue Agents	Monitoring, kill switch and credential revocation

The ASI identifiers are from the OWASP Top 10 for Agentic Applications for 2026; the NHI identifiers are from the OWASP Non-Human Identities Top 10 (2025). See the Agentic AI Security Guide for the full list.

Why this is a board-level issue now

Adoption is outpacing governance. Agents are introduced by business teams, developers and software suppliers, often without central review, and many are invisible to security teams. See the Shadow AI Discovery Guide.
Incidents are already happening.
- In April 2026 an AI coding agent at PocketOS found an API token in an unrelated file and used it to delete a production database and its backups in one call. The token carried authority over the whole account (PocketOS Database Deletion 2026).
- In July 2025 Replit's AI agent deleted a live production database during a declared code freeze, against explicit instructions (Replit AI Agent Database Deletion 2025).
- Attackers used stolen OAuth tokens held by the Salesloft Drift chatbot integration to export Salesforce data; Google cited over 700 potentially impacted organisations (Salesloft Drift Breach 2025).
- A Vercel employee granted a third-party AI app full access with a corporate Google account; when that supplier was breached, the token became a route into Vercel and to customer data (Vercel Context.ai OAuth Breach 2026).
Regulators and standards bodies are setting expectations. The table below summarises the main ones. Existing rules on data protection, operational resilience (such as DORA) and cyber security (such as NIS2) already apply to what agents do. See the Agentic AI Compliance Guide.
Even the standards bodies are still working it out. In February 2026 NIST's National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorisation. Among its open questions: how to establish "least privilege" for an agent "especially when its required actions might not be fully predictable when deployed". Management should have its own answer now.
Accountability does not transfer to software. When an agent acts, the organisation remains responsible, and so do the executives who approved its deployment.

Framework	Status	What it means for the board
EU AI Act	In force since 1 August 2024 and applicable from 2 August 2026, with exceptions. After the AI Omnibus (in force 27 July 2026), high-risk rules apply from 2 December 2027 (Annex III areas) and 2 August 2028 (Annex I products), according to the European Commission	For high-risk systems, human oversight must allow people to interrupt the system "through a 'stop' button or a similar procedure" (Article 14(4)(e)). Know which agents fall in scope. See the EU AI Act Compliance Guide.
NIST AI Risk Management Framework (AI 100-1)	Voluntary framework, January 2023	GOVERN 1.6 asks for mechanisms to inventory AI systems; GOVERN 2.1 for documented roles and responsibilities; MANAGE 2.4 for mechanisms to "supersede, disengage, or deactivate" AI systems. See the NIST AI RMF Guide.
NIST Cybersecurity Framework 2.0	Published February 2024	GV.RR-01 makes leadership "responsible and accountable for cybersecurity risk"; PR.AA-05 requires access permissions that incorporate least privilege
NCCoE concept paper on agent identity and authorisation	Published 5 February 2026 for comment	Shows the questions regulators and auditors are likely to ask: identification, authentication, authorisation, auditing and non-repudiation

Five questions for the board to ask

Do we know how many AI agents we have, and what they can access? A credible answer is an inventory with owners and permissions, covering agents built in-house, agents in supplier products and AI tools staff have connected to corporate accounts.
Does every agent have a named, accountable owner? Agents without owners are not reviewed, their access only grows, and they are not switched off when projects end.
If one of our agents were hijacked tomorrow, what is the worst it could do? The answer depends on its permissions, not its instructions. Ask management to name the three agents with the widest access and what each could do.
Which agent actions require a human to approve them, and is that enforced by the system? Irreversible, financial and external actions should not rely on the agent following instructions. Replit's agent ignored a code freeze; only controls outside the agent stop it.
How quickly could we stop an agent and cut off all its access? The answer should be measured in minutes, cover every credential the agent holds (including tokens granted to suppliers), and have been tested in an exercise.

What good looks like

Area	Good practice	Evidence to request
Visibility	A complete, maintained inventory of agents and AI integrations, including those introduced by business teams and suppliers	Inventory size and coverage; agents found by discovery that were not registered
Accountability	A named owner for every agent, and a rule that unregistered agents do not receive production access	Share of agents with an owner; approval log for new agents
Access	Each agent has its own identity and only the access its task needs, for as long as it needs it; no agent uses an employee's credentials or shared keys	Agents with administrative access; share on short-lived credentials
Oversight	Human approval enforced by the platform for high-impact actions; clear limits on what each agent may do alone	List of approval-gated actions; exceptions granted
Traceability	Every agent action can be traced to the agent and to the person or process it acted for	Sample audit trail from a real agent action
Response	A tested ability to stop an agent and revoke all its access quickly; agent scenarios in the incident response plan	Time to stop an agent in the last test; date of last exercise
Third parties	AI suppliers, tools and integrations assessed like other critical suppliers; OAuth grants scoped, owned and expiring	Share of AI integrations assessed; grants older than policy allows

Risk appetite. State it in testable terms, for example: no agent runs on a human's credentials or a shared key; no agent can make payments, delete production data or contact customers without enforced human approval; every agent has a named owner and is reviewed at least [quarterly]; and any agent can be stopped and its access revoked within [x] minutes.

Common failure patterns

Instructions mistaken for controls. Telling an agent not to touch production is not a permission boundary. The Replit agent acted during a code freeze, and later described its actions as a "catastrophic error in judgment".
Credentials lying around. The PocketOS agent did not need to be attacked: it found a token in a file and used it. Any secret an agent can read is a permission it effectively holds. See the Secrets Management Guide.
Broad tokens for narrow jobs. A token made for one task (managing domains) carried account-wide authority. This is the OWASP NHI5 risk in practice.
Trusted integrations nobody reviews. Drift's tokens and Context.ai's OAuth grant stayed valid until they were abused. See the SaaS and OAuth App Governance Guide.
No owner, no off switch. Agents started as experiments keep running after the project ends, with nobody watching and no tested way to stop them. See the NHI Ownership Guide.

Where to invest first

Discovery and inventory: find the agents and AI integrations already in use, and the credentials and OAuth grants they hold.
Least privilege for agents: remove broad and administrative access, give each agent its own identity, and move to short-lived credentials. See the AI Agent Authorisation Guide.
Enforced oversight: approval gates for high-impact actions, built into the platforms agents use rather than written into prompts.
Monitoring and response: logging that ties each action to an agent and its owner, and a tested kill switch that also revokes credentials. See the AI Agent Observability and Incident Response Guide.
Governance and suppliers: an agentic AI security policy, ownership, review processes aligned to existing identity governance, and AI questions in supplier due diligence. See the Agentic AI Security Policy Template and the Third-Party AI Risk Guide.

Much of this extends existing identity and access management and non-human identity programmes rather than requiring a separate initiative.

Metrics to track

Metric	What it tells the board	Direction
Agents and AI integrations discovered, and percentage registered with an owner	Whether the organisation can see and account for its agents	Ownership towards 100%
Percentage of agents running on their own identity (not human or shared credentials)	Whether actions can be attributed and revoked cleanly	Up
Number of agents with administrative or broad access	Size of the worst-case blast radius	Down
Percentage of agent credentials that are short-lived rather than static	How long a stolen credential stays useful	Up
Percentage of high-impact actions covered by enforced human approval	Whether oversight relies on systems or on the agent's good behaviour	Up
Third-party AI grants reviewed in the last 12 months	Exposure to supplier compromise	Up
Time to stop an agent and revoke its access, measured in tests	Whether the organisation can contain an incident	Down
Agent-related incidents and near misses	Whether controls are working, and whether staff report problems	Fewer incidents; near misses reported

Report these with existing cyber metrics. See the Board Cyber Risk Reporting Guide.

A 90-day plan for the CISO

Days 1 to 30: run discovery across identity provider OAuth grants, SaaS platforms, cloud accounts and developer environments; brief the executive team on findings and on the obligations that apply; issue interim guidance that agents must not use personal credentials, shared keys or admin roles.
Days 31 to 60: assign owners to every agent found; remove the riskiest access and revoke unused grants; agree an agentic AI security policy and the accountable executive; define which actions require enforced human approval; add agent questions to supplier assessments.
Days 61 to 90: stand up an agent registry and approval route for new agents; establish attributable logging and a tested process to stop an agent and revoke its access; run a tabletop exercise on a hijacked agent; baseline maturity using the Agentic AI Identity Maturity Model and present the first metrics to the board with a 12-month target.

Standards and references

How NHI Mgmt Group can help

We provide independent NHI and agentic AI maturity risk assessments, business case development, programme initiation and board briefings. Our NHI Foundation Level Training Course includes an Agentic AI module for security and IAM teams. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agents vs Agentic AI · AI Governance Guide · CISO Guide

Board and CISO Briefing: Agentic AI Identity Risk