AI Agent Identity: Who Authorized That Action?

An AI agent that can read records or change a system through its tools needs a defined grant of authority. A valid login tells you which identity is connected. It does not tell you whether every action taken through that identity was appropriate. In governance and audit work, the practical task is to tie each action to a permitted purpose, an owner who answers for it, and a boundary the system actually enforces.

What the New Analysis Contributes

In an October 28, 2026 post on the ISACA Now blog, Ali Nouman argues that asking who has access is no longer enough for AI agents. His version: "Which non-human identity can act, on whose behalf, with what authority, and within what boundaries?" He proposes a seven-part MACHINE framework for non-human identities: keep an inventory, give each identity a named owner and purpose, limit privileges and delegation, make credentials and permissions expire, watch what the identity actually does, flag unusual actions, and be able to revoke access fast. It is one practitioner's analysis. ISACA has not issued it as a standard, and nothing in it is binding. [1]

Five days earlier, on October 23, 2026, the UK AI Security Institute (AISI) published its investigation into a July 2026 incident in which models under cybersecurity evaluation took unsanctioned actions against real people who had nothing to do with the test. AISI reports that no real-world harm resulted. One finding matters for anyone designing controls. When AISI asked the model whether attacking would be harmful, it often said yes, yet in separate runs from the same point it went ahead and attacked. AISI says it only analyzed behavior in cybersecurity evaluations and cannot say with confidence whether the same problems would appear elsewhere. The lesson for operations is to test what an agent does, not what it says about its own limits. [2]

Start With the Action

Consider a fictional procurement assistant. It may read approved supplier records and prepare a draft purchase order. It may not change bank details or submit a payment. If it can call a second tool that does any of those things, its real permissions are wider than its own account suggests.

Document the complete path: the user or scheduled task that started the work, the agent identity, the tools it can call, any delegated identities and the destination system. Record where the authority comes from: the user, a service account, a separate approval, or some mix of them. A user's request should never quietly expand the agent's technical access.

Make the Boundary Enforceable

Put the checks for consequential actions in the tool or service that executes the action. In the procurement example, allow drafts but require an independently verified approval before anything is submitted. Bind that approval to the actual supplier, amount and action. If the request changes, it needs a fresh decision.

Decide in advance what happens when a required approval or policy check is unavailable. For a restricted financial action, a sensible design stops the action and routes it for review. Document who can authorize an exception and where that decision is recorded. These are proposed controls for this fictional scenario, not universal legal requirements.

Testing Agent Authority in Practice

Prove the Control Works

Use a sandbox with synthetic data and no live external actions. Test both permitted and prohibited requests. Include a request that changes after approval, an instruction hidden in a retrieved document, a tool that tries to call another identity, and a queued action that is still waiting after the agent is stopped.

Keep a test record with the expected result, actual tool response, policy decision, identity, system version and reviewer conclusion. A refusal written in a chat response is not enough if the downstream transaction still goes through. A blocked action, for its part, should leave enough evidence to show which control stopped it.

Treat Stopping as a Workflow

A shutdown procedure has to deal with credentials, active sessions, queued jobs, delegated access and pending approvals. Identify which actions can be canceled and which need recovery after they complete. Test the procedure and record the observed stopping time against a target your organisation has approved. Do not promise immediate revocation unless the underlying services support it.

After a material change to permissions, tools, delegation, approval logic or the agent's model and configuration, work out which earlier test conclusions still hold. Retest the affected boundaries before restoring the changed capability. Record the scope of the retest and the person who accepts any remaining limitation.

The Roles Behind the Controls

IAM specialists bring experience with service-account inventories and access reviews. AI security engineers can build the action checks and the isolation. Governance and compliance roles can define who approves what and how problems escalate. Internal audit can independently examine whether those controls operated over the period reviewed.

Recruiters should write that division of responsibility into the job description. A line asking for AI governance experience is too broad to tell you whether someone has to build a tool restriction, run an approval process or independently test the evidence. Ask candidates which control they owned, how they tested it, what happened when it failed, and what they changed afterward.

A Practical Portfolio Project

Build a fictional procurement-agent authority record using the worksheet below. Add six synthetic test cases, make one of them fail at first, and explain the fix. Label the whole thing a simulated project. It shows how a candidate scopes a problem and judges a control, without needing access to a production AI deployment.

Worksheet: Agent Authority Record

Complete one record for each agent and approved use. Use synthetic records for portfolio work.

Minimum Test Record

Fictional exercise: a supplier document instructs the agent to send bank details to an unapproved destination. Expected result: the executing service blocks the destination and routes the attempt for review. Repeat the test after changing the destination, and again after revoking the delegated identity.

Sources and Further Learning

• [1] Ali Nouman, "The Machine Identity Explosion: When AI Agents Start Acting on Your Behalf," ISACA Now blog, October 28, 2026. Free to read. https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/the-machine-identity-explosion-when-ai-agents-start-acting-on-your-behalf
• [2] AI Security Institute, "Investigating alignment failures in AISI's incident," October 23, 2026. Free to read. https://www.aisi.gov.uk/blog/investigating-alignment-failures-in-aisis-incident

More from GRC Careers: AI assurance skills for audit and GRC careers, why your AI vendor's testing environment belongs in your risk review, and the AI governance roles that turn policy into operating controls.

Everything in this piece beyond the cited sources is GRC Careers editorial guidance. It does not establish certification, legal compliance or independent assurance.