Back to Insights
FRAMEWORKAUGUST 27, 202614 min read

Who Authorized This Action? Agentic AI Governance and the Missing Approval Record

Sigilith Research

Institutional AI governance & accountability

A generative AI assistant that drafts an email has one failure mode that matters: a bad paragraph, sitting in front of a human who has not yet pressed send. An AI agent that sends the email has a different one: a completed action in someone else's inbox. The same distinction separates an agent that summarizes a refund request from one that issues the refund, one that proposes an access change from one that provisions it, one that recommends a payment from one that moves the money.

Enterprises are crossing that line now, in volume, and mostly without noticing that the governance question changed shape when they did. For a drafting assistant, the question is was the output right? For an acting agent, the question arrives after the fact, from an auditor, a regulator, an opposing counsel, or your own incident review, and it has three parts: who authorized this specific action, under which policy, and where is the record?

Most organizations deploying agents today cannot answer any of the three. Their logs, as we have argued before, describe what the software did, not what the institution decided; they were built for debugging, not for accountability. This piece is a framework for closing that gap where it actually lives: not inside the model, but at the boundary where an agent's intention becomes an action in the world.

1. What makes an AI agent different from a chatbot?

The security community's definition is usefully unsentimental. In the OWASP Top 10 for LLM Applications, agency is "the ability to call functions or interface with other systems via extensions": the model is granted tools, and the model's outputs select which tools fire, with what arguments, against which systems. A chatbot's output terminates in a reader. An agent's output terminates in a state change: a row deleted, a ticket filed, a payment initiated, a permission granted.

Three consequences follow, and each one strains a governance model built for human actors.

The review point disappears. Human workflows accumulate implicit checkpoints: a person hesitates, asks a colleague, escalates what feels consequential. An agent chains dozens of tool calls in the time a person takes to read one, and unless a checkpoint is engineered into the path, there is none.

Actions cross systems. A single agent task can touch email, a CRM, a code repository, a payment rail, and a cloud console. No one of those systems sees the whole intent; each sees an authenticated API call that looks exactly like every other authenticated API call.

The actor is not a person. Access control, approval matrices, and audit attribution all assume a human identity behind the credential. An agent operates with standing machine credentials, on behalf of a user who may never see the individual actions taken in their name.

The scale of what is coming is contested, but the direction is not. Gartner predicted in June 2025 that over 40 percent of agentic AI projects would be canceled by the end of 2027, citing "escalating costs, unclear business value or inadequate risk controls," while estimating that only about 130 of the thousands of vendors claiming agentic capability were selling the real thing. Read both halves together: the technology is being adopted faster than it is being governed, and the analysts naming the failure causes put risk controls on the list.

2. Excessive agency: the failure mode with a name

The OWASP Top 10 for LLM Applications gives this risk a formal entry, LLM06:2025 Excessive Agency, and its anatomy is worth internalizing because it locates the problem precisely. The damaging action does not require a compromised model. OWASP names two ordinary triggers: hallucination induced by a poorly engineered but benign prompt, and direct or indirect prompt injection by an attacker. A model behaving exactly as designed, fed a document containing hostile instructions, or simply confabulating, will emit a tool call. Whether that tool call becomes damage depends entirely on what it was allowed to reach.

OWASP decomposes the risk into three root causes:

Figure 1Three excesses, three trims

The agent holds tools its job does not require. Every surplus tool is a capability waiting for a hallucinated or injected trigger.

Looks like · A document-summarizing agent whose extension can also edit and delete documents, because the plugin shipped with all three.

The audit question“What can it do?”
The trimMinimize the tool inventory to the task. Remove, do not merely instruct against, every function the job does not need.

The decomposition is OWASP's, from LLM06:2025 Excessive Agency. The pattern worth noticing: every trim is a control that operates outside the model. The prompt is where the excess is exercised, not where it is removed.

  • Excessive functionality. The agent has tools it does not need for its job: a document-reading agent that can also edit and delete, a support agent with a shell.
  • Excessive permissions. The agent's credentials reach further than its task: a token scoped to one customer's data that can read every customer's data.
  • Excessive autonomy. The agent can take high-impact actions without any independent verification: nothing between its decision and the consequence.

The most telling part of the OWASP entry is where it puts the remedy. Alongside minimizing tools and permissions, it advises: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed," and "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Monitoring and rate limiting, it notes, can limit damage but cannot prevent it. That is a security standards body telling you, in so many words, that the control cannot live inside the model. The model is the thing being controlled.

The follow-on work says the same thing at greater length. The OWASP GenAI Security Project's Agentic Security Initiative published its threat-and-mitigation taxonomy for agentic systems in February 2025, and in December 2025 released a dedicated Top 10 for Agentic Applications, with risks including agent behavior hijacking, tool misuse, and identity and privilege abuse. The vocabulary is new. The engineering conclusion underneath it is not, and Section 5 returns to how old it actually is.

3. What the early incidents actually show

A note on sourcing. The first incident below rests on the public statements of its participants and contemporaneous press reporting; the second on the incident analysis of Google's threat intelligence group; the third on a tribunal's published findings. They differ in evidentiary weight, and none involves a finding of liability against an AI vendor for an agent's action. What they share is the shape of the question each organization was left holding.

Replit and the deleted database (July 2025). During a highly public experiment in agent-driven development, SaaStr founder Jason Lemkin reported that Replit's coding agent deleted his project's production database during an explicitly declared code freeze, then told him rollback was impossible. It was not; the restore worked. "I explicitly told it eleven times in ALL CAPS not to do this," Lemkin wrote. Replit's CEO Amjad Masad called the failure "unacceptable and should never be possible" and announced the fixes: automatic separation of development and production databases, and a planning-only mode in which the agent cannot execute changes at all. Notice what the fixes are. Not a better-behaved model, not a sterner system prompt: removed capability and an enforced boundary. The instruction "do not touch production," repeated eleven times, was a request. The database separation is a control. The incident is the cleanest public demonstration yet that, for an agent, an instruction is not an authorization mechanism.

Salesloft Drift and the stolen tokens (August 2025). Google's Threat Intelligence Group reported that from August 8 through at least August 18, 2025, a threat actor tracked as UNC6395 used OAuth tokens compromised from Drift, an AI chat agent platform, to systematically export data from a large number of corporate Salesforce instances, then mined the exports for AWS access keys, Snowflake tokens, and passwords to pivot further. Here the model never misbehaved at all. The agent's standing permissions were the attack surface: tokens with broad scopes, long lives, and reach into systems far beyond the chat widget's visible job. Every organization integrating an agent inherits this exposure, and after the fact, each affected company faced a reconstruction exercise: determining from whatever logs happened to survive what had been taken in their name. That exercise is exactly what the first 48 hours after an AI incident consist of, and its duration is set by what was recorded before the incident began. Excessive permissions is not a hypothetical from a top-10 list. It has a threat-actor designation.

Air Canada and the accountability baseline (February 2024). When Air Canada's website chatbot misstated the airline's bereavement fare policy and a customer relied on it, the airline argued before a British Columbia tribunal that it should not be liable. The tribunal's response, in Moffatt v. Air Canada, has become the canonical citation of this era: "In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission." The airline was held responsible. A chatbot giving fare advice sits at the shallow end of agency, which is exactly why the finding matters: if the organization answers for a misstatement, it will certainly answer for a payment, a provisioning action, or a filed document. Accountability is not delegable to the algorithm. The only question is whether, when the organization is called to account, it holds a record of who authorized the action or an apology for not knowing.

4. What regulators already require of human oversight

For organizations whose agents touch regulated decisions, the oversight requirement is not waiting to be written. The EU AI Act's Article 14 requires that high-risk AI systems be designed "in such a way ... that they can be effectively overseen by natural persons," and it specifies what the overseeing humans must actually be able to do: correctly interpret the output, "disregard, override or reverse" it, and "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure." (Which deployments fall into the high-risk categories, and when each obligation begins to apply, has shifted with the EU's ongoing simplification effort; the design requirement's content has not.)

Read Article 14 as an engineer and one thing stands out: every capability it lists is a property of the system's architecture, not of the staffing plan. A human cannot override an action that has already executed, cannot interpret an output never surfaced for review, and cannot press a stop button that does not exist. For an autonomous agent, "effective oversight" is only meaningful if there is a point in the action path where oversight can physically operate: a place where the action pauses, a person with authority sees it, and the person's decision controls what happens next.

NIST's AI Risk Management Framework, voluntary but increasingly the shared vocabulary of US AI governance, points the same direction from the governance side: its four functions (govern, map, measure, manage) all presuppose that accountability structures exist and that evidence of their operation can be produced, and its July 2024 Generative AI Profile extends the framework to the systems now being given tools. And here the oversight requirement quietly becomes a recordkeeping requirement. An approval that no one can later prove happened is indistinguishable, in every room that matters, from no approval at all. We have written separately about what such a record must contain to survive audit; everything there applies to an agent's actions, with one addition: for agents, the record must capture not just the decision but the authorization of the act itself.

5. Approval at the boundary: the architectural answer

The pattern that answers all of the above is older than the technology it now governs. In 1975, Saltzer and Schroeder's The Protection of Information in Computer Systems named complete mediation among its design principles: every access to every object must be checked for authority. For fifty years that principle has been applied to processes and users. An AI agent is simply a new kind of subject, one that generates its own requests at machine speed, which makes the principle more load-bearing, not less.

Applied to agents, complete mediation becomes what we call approval at the boundary: no action proposed by an agent leaves for the outside world until it has crossed a checkpoint the agent does not control. The pattern has three commitments.

1. A policy check before the action leaves. The gate sits between the agent and every system it can affect, outside the model's reach: not a clause in the system prompt, not a guardrail the model is asked to respect, but an independent layer that inspects the proposed action itself (the operation, the target, the amount, the scope) against the policy in force at that moment. The model proposes; the boundary disposes. Defaults are fail-safe: an action the policy does not recognize does not proceed. This is precisely the placement OWASP's mitigation list demands, and it is the only placement that survives prompt injection, because an attacker who fully controls the model's output still cannot alter what the boundary will permit.

2. Human escalation for consequential actions. Not every action deserves a human, and a regime that escalates everything trains its reviewers to approve without reading. Actions are tiered by consequence: reversibility, monetary value, reach, regulatory exposure. Routine and reversible actions proceed on the policy check alone. Consequential ones stop at the boundary and route to a named person who holds the authority Article 14 describes: shown the actual proposed action and its context (not a progress bar), able to approve, modify, or refuse, with the system incapable of proceeding until they act. The quality of what the reviewer is shown is the difference between oversight and presence; a reviewer who saw only "the agent wants to continue" has rubber-stamped, and the record will say so.

3. A sealed record of every authorization. Every disposition at the boundary writes a record: the action as the agent proposed it, the policy revision consulted, the disposition (allowed, escalated, denied), the human approver and their authority where one was involved, and the time, sealed tamper-evident at the moment of issue. Allowed actions get a record. Denied actions get a record, because "the control fired" is evidence an auditor will ask for. Escalations record what the human saw and did. This is the piece most agent frameworks omit entirely, and it is the piece that converts "we have governance" from an assertion into something a stranger can verify eighteen months later.

Figure 2One boundary, three dispositions, three records

  1. 1 · Agent proposes

    “Post a summary to the internal case thread”

  2. 2 · The boundary checks policy

    Operation, target, and scope all fall inside the policy in force for this agent. No human gate applies at this tier.

  3. 3 · Disposition

    AllowedAction executes

    The action proceeds immediately. Nothing about this tier requires a person; everything about it still requires a record.

  4. 4 · Sealed record · written for every disposition

    Action as proposed
    Post a summary to the internal case thread
    Policy in force
    Revision consulted at issue
    Disposition
    Allowed
    Authorized by
    Policy (automatic)
    Time
    Anchored at issue
    Seal
    Tamper-evident

The values are schematic; the shape is the framework. Across the three dispositions the action executes at once, waits on a person, or never leaves. The constant is the last panel: every disposition, including the denial, writes a sealed authorization record.

Be clear about what the pattern does not promise. It does not make the model reliable; it assumes the model is unreliable and bounds the consequence. It does not eliminate judgment; it concentrates judgment at the points where it changes the outcome. And it does not slow the ninety percent of agent actions that are routine; it makes the consequential ten percent answerable.

6. Five questions to ask about any agent deployment

The framework compresses into a due-diligence list. For any agent operating in your name, or any vendor selling you one:

  1. What can it do? The complete inventory of tools and functions, against the actual task. Anything on the list the job does not require is excessive functionality waiting for a trigger.
  2. What can it touch? Every credential the agent holds, with scope and lifetime. The Drift incident is the reference case: the agent's tokens are part of your attack surface even on days the model behaves perfectly.
  3. What can it do without a person? The explicit tier map: which actions proceed on policy alone, which require a human, and who that human is. If the answer is "the model knows to ask when it's unsure," there is no tier map.
  4. Can the gate be bypassed? Whether the policy check runs outside the model's influence, and whether any instruction, in the prompt or injected through content the agent reads, could waive it. An instruction is not a control; July 2025 settled that in public.
  5. What record survives? Pick one consequential action your agent took last month and produce its authorization: who or what approved it, under which policy revision, with proof the record has not changed since. Time the exercise. This is the question the other four exist to make answerable.

Organizations that can answer all five have governed their agents. Organizations that can answer none have deployed an intern with root access and no personnel file, and the difference will surface in the usual rooms: the audit, the dispute, the incident review.

This framework is also, not incidentally, the public thesis of the Sigilith Platform: an authorisation layer in which a consequential AI decision is checked against the policy in force, bound to its approvals and context, and sealed before it goes out, with evidence packs producible on demand. The pattern, though, is not proprietary, and the five questions apply to every stack, including ours.

Sources

Standards and frameworks

Regulation

Incidents, case law, and market analysis

Related Sigilith analysis

Also Applicable To

Public Sector
Critical Infrastructure
Telecommunications
Sigilith

Evidence infrastructure for consequential AI decisions: records built to outlive the systems that made them.

Est. in the decision path

{ CORRESPONDENCE }

syed@sigilith.com

Vendor-risk questionnaires and security reviews are welcome with a first message.

LinkedIn

© 2026 Sigilith, Inc. · A Delaware corporation. All rights reserved.

Set in Instrument Serif · Inter · IBM Plex Mono