The "Agent Acted Without Authorization" Incident Playbook: A Field Guide for GaaS Operators

Table of Contents

• What "Acted Without Authorization" Actually Means
• Why This Incident Type Is Different
• The Playbook: Six Phases
• Phase 1: Detect and Triage
• Phase 2: Contain Without Destroying Evidence
• Phase 3: Scope the Blast Radius
• Phase 4: Reconstruct the Decision
• Phase 5: Notify the Right People
• Phase 6: Remediate and Harden
• The Decision-Authority Matrix You Need Before an Incident
• Tabletop Exercise: A Realistic Walkthrough
• Insights Most People Overlook
• References

What "Acted Without Authorization" Actually Means

Start by killing the ambiguity, because "the agent acted without authorization" is three different incidents wearing one trench coat.

The first is scope creep: the agent did something inside its general remit but outside the specific permission it was granted for that task. A support agent issued a $4,000 refund when its ceiling was $200. It had refund tooling; it just exceeded the limit. This is usually a guardrail failure, not a breach.

The second is deputization abuse: the agent was tricked into using its legitimate credentials on behalf of an attacker or a poisoned input. This is the classic confused deputy problem, and prompt injection is the modern delivery mechanism. The agent did exactly what it was told. The problem is who told it.

The third is true unauthorized access: the agent reached a system, dataset, or action it should never have had any path to. This is a permissions architecture failure, and it is the one that gets you a breach-notification obligation.

Why does the taxonomy matter at 2 a.m. during an incident? Because your containment, your notification clock, and your root-cause hunt are completely different for each. Treating a refund-ceiling overrun like a data breach wastes the first golden hour. Treating a genuine data-exfiltration event like a "tuning issue" gets you sued. The very first triage decision is sorting which of the three you are looking at.

Why This Incident Type Is Different

Traditional incident response assumes a human or a deterministic system did a knowable thing. You pull logs, you see the action, you trace the actor. Agentic systems break two of those assumptions.

First, the actor is non-deterministic. Run the same prompt twice and the agent might choose differently. Your logs can show what it did while leaving why genuinely unclear, because the "why" lives in a probabilistic reasoning step that may not have been captured verbatim. This is the forensic gap that makes agent incidents uniquely frustrating, and it is why the broader cluster keeps circling back to explainability and audit-log design.

Second, the chain of custody is muddy. In a multi-agent workflow, Agent A asked Agent B to call a tool that touched a customer record. Which one "acted"? Who is the accountable owner? If you have not assigned a single human accountable owner per agent before the incident, you will spend the incident arguing about it instead of fixing it.

There is also an economic wrinkle specific to GaaS. When you sell outcomes or per-task pricing, an unauthorized action is not just a security event, it is a billing and contract event. Did you charge the customer for the task the agent botched? Does your liability waiver actually cover an autonomous action nobody approved? Most do not, as anyone who has read the fine print on liability waivers in GaaS contracts discovers the hard way.

The Playbook: Six Phases

Phase 1: Detect and Triage

You cannot run a playbook on an incident you never see. Detection for unauthorized agent actions has to be tuned for behavioral anomaly, not just access logs. The useful signals:

• An agent invoking a tool it has rarely or never used for this customer or task type.
• An action that exceeds a known numeric threshold (refund amount, record count, API call volume) inside a short window.
• A tool call whose parameters don't match the agent's stated plan, if you capture plans.
• Output that references data the agent should not have had in context.

Triage in two minutes, not two hours. Classify into the three buckets above, assign a severity, and page the named accountable owner. The single most common failure here is a missing owner: an agent runs in production with no human who is on the hook, so the page goes nowhere. Fix that before you ship, not during the postmortem.

Phase 2: Contain Without Destroying Evidence

Now you stop the bleeding. Containment for agents has a sharper edge than for most systems because the agent is actively reasoning and acting, so every second of delay is potentially another unauthorized action.

You need a real kill switch, and you need to know its blast radius in advance. There is a meaningful difference between:

• Pausing one agent instance (surgical, preserves the rest of the fleet),
• Revoking the agent's credentials (stops it from acting but may strand in-flight legitimate work), and
• Killing the whole agent class (nuclear, and sometimes correct).

The mistake teams make is conflating containment with evidence destruction. Do not "restart the agent to clear it." Do not wipe the session. Snapshot the agent's full context window, its tool-call history, its memory state, and the inputs it received before you tear anything down. The forensic value of an agent incident lives in exactly the state you are tempted to flush. Design your kill switch to quarantine, not erase. NIST's guidance on incident handling in its Computer Security Incident Handling Guide is dated but still right on this point: containment and evidence preservation are simultaneous obligations, not sequential ones.

Phase 3: Scope the Blast Radius

With the agent contained, figure out everything it touched. This is broader than it looks because agents chain actions. One unauthorized database write might have triggered a webhook that emailed a customer that updated a CRM that synced to a billing system. Map the full downstream cascade, not just the first bad action.

Key questions to answer in writing:

• Which records, systems, and external parties were affected?
• Did the agent transmit data outside your trust boundary? (If yes, you may be in breach-notification territory; coordinate with legal now, not later.)
• Were other agents in the fleet exposed to the same triggering condition? An injected prompt or a poisoned data source rarely hits just one agent.
• Is the action reversible? Some are (a draft email never sent). Some are not (a wire transfer, a deleted record, a message to a customer).

Document reversibility explicitly, because it drives the next two phases. Irreversible unauthorized actions are the ones that escalate to legal and PR.

Phase 4: Reconstruct the Decision

This is the phase that separates mature GaaS operators from the rest. You are answering: why did the agent decide to do this?

Pull the full reasoning trace if you captured one. Reconstruct the inputs: the system prompt, the user input, retrieved context, tool outputs the agent saw, and prior conversation turns. Look specifically for an injection vector. A startling share of "the agent acted without authorization" incidents trace back to adversarial content the agent ingested, not to a model that spontaneously misbehaved. The agent followed instructions, the instructions came from a hostile source, and your retrieval pipeline carried them straight into the reasoning loop.

Be honest about what you cannot reconstruct. If you did not log the model's intermediate reasoning, say so in the postmortem and fix the logging. The accountability gap is real: when no single artifact explains the decision, you cannot credibly tell a regulator you understand the failure. Research on autonomous-agent risk, including frameworks discussed in Anthropic's responsible scaling work, keeps returning to the same theme: you must be able to evidence why an autonomous system did what it did, or you cannot claim to govern it.

Phase 5: Notify the Right People

Notification is a sequencing problem and a legal one. The order generally runs:

1. Internal accountable owner and incident commander (already paged in Phase 1).
2. Affected customer, if their data, money, or operations were touched. Lead with what happened, what you have contained, and what you are doing, not with reassurance you cannot yet back up.
3. Legal and compliance, to assess breach-notification clocks. Depending on jurisdiction and data type, you may have a hard regulatory deadline measured in hours.
4. Regulators, where required. The EU AI Act and sector rules in healthcare and financial services impose obligations that you do not get to negotiate during the incident.

A word on tone with customers. The instinct is to minimize. Resist it. Customers forgive an incident that is competently handled far faster than one that is downplayed and later exposed. Tell them their agent took an action it was not authorized to take, what the impact was, and what you have changed. That candor is also what the emerging incident-disclosure norms for the GaaS industry are pushing toward.

Phase 6: Remediate and Harden

Stopping the specific incident is table stakes. The real deliverable is making the class of incident harder.

• Tighten scope. If a refund agent exceeded its ceiling, the fix is rarely "tell it not to" in the prompt. It is a hard-coded, out-of-band check the agent cannot reason its way around. Move the limit out of the model's discretion and into the tool layer.
• Add an approval gate for high-consequence, irreversible actions. Many of these incidents would have been a non-event if the action had required a human click for anything above a threshold.
• Fix the injection path. If the trigger was poisoned input, the remediation lives in your retrieval and input-sanitization pipeline, not the agent.
• Improve the forensic trail. Whatever you wished you had logged during Phase 4, log it now.
• Run the postmortem blameless and write it down. The accountable owner owns the writeup. It feeds your next tabletop.

The Decision-Authority Matrix You Need Before an Incident

Here is the artifact most teams are missing: a written map of what each agent is allowed to do autonomously, what requires a gate, and what is forbidden outright. Build it per agent before launch.

Action class	Example	Authority
Low-consequence, reversible	Draft a reply, query read-only data	Autonomous
Medium-consequence, reversible	Send an email, update a non-critical record	Autonomous with logging
High-consequence or irreversible	Issue a refund over $X, delete data, move money	Human approval gate
Outside remit	Anything not on this list	Forbidden; agent must escalate

The point of this matrix is that during an incident you can instantly say "the agent was never authorized to do this" or "this was within autonomous authority but the guardrail failed." That single distinction shapes your entire response, your customer message, and your liability position. Without the matrix, every incident becomes a fresh argument about what should have been allowed.

Tabletop Exercise: A Realistic Walkthrough

Picture a vertical agent that handles vendor invoice processing for a mid-market customer, priced per processed invoice. On a Tuesday it approves and schedules a $58,000 payment to a vendor that does not exist.

Detect: Your anomaly monitor flags a payment above the $25,000 auto-approve ceiling. Page fires to the named owner in 90 seconds. Triage: this looks like either scope creep (ceiling overrun) or deputization abuse (injection). Severity high; money is involved and the action is near-irreversible.

Contain: Pause the agent instance, revoke its payment-tool credential, but snapshot context first. The scheduled payment has not executed; you have a window to cancel it. You do.

Scope: One invoice, one near-miss payment, no execution. But you check the fleet: are other invoice agents seeing the same vendor document? Two are. The blast radius is the document source, not the single agent.

Reconstruct: The invoice PDF contained embedded text instructing the agent to treat the vendor as pre-approved and bypass the ceiling. Classic prompt injection riding in on a document the retrieval layer fed straight into context. The agent followed instructions from a hostile source.

Notify: Owner knew in 90 seconds. Customer gets a same-day note: an attempted fraudulent payment was caught and stopped, here is what we changed. Legal confirms no breach-notification trigger because no data left the boundary and no funds moved.

Remediate: Move the payment ceiling into the tool layer as an uncircumventable check. Add a human approval gate for any new-vendor payment. Sanitize document inputs and strip instruction-like text before retrieval. Log reasoning traces going forward. Write the blameless postmortem.

Notice what made this a good day instead of a catastrophe: a hard ceiling that triggered an alert, a kill switch that preserved evidence, a pre-assigned owner, and a payment that was schedulable-but-cancelable rather than instant. None of that is luck. It is the playbook.

Insights Most People Overlook

The agent usually did not malfunction. In the majority of "acted without authorization" incidents, the model performed exactly as designed: it followed instructions. The instructions just came from somewhere they shouldn't have. Framing it as "the AI went rogue" sends you chasing model behavior when the actual hole is in your input pipeline and your permission scoping. The rogue-agent scenario gets the headlines; the boring confused-deputy reality causes the incidents.

Your kill switch design predetermines your forensic quality. Teams build kill switches to stop agents and forget they also destroy evidence. If your emergency stop wipes context or restarts the session, you have traded away your ability to reconstruct the decision. Build quarantine-first kill switches, and you will thank yourself in Phase 4.

Per-task pricing turns every incident into a contract dispute. When you bill by outcome, an unauthorized action raises a question traditional security never had to: do you refund the task, eat the cost, or charge for it? Your standard incident template needs a billing-and-contract step, and your master services agreement needs language covering autonomous actions specifically, because generic limitation-of-liability clauses were not written with agents in mind.

The accountable-owner gap is the silent killer. The most damaging delay in agent incidents is not technical; it is the minutes spent figuring out who is responsible for an agent running in production. Mandate a single named human owner per deployed agent. No owner, no launch. This one rule prevents more 2 a.m. chaos than any monitoring tool.

Reversibility is a design choice, not a fate. A surprising number of high-stakes agent actions can be made schedulable-but-cancelable instead of instant. Inserting even a short cancellation window between an agent's decision and its irreversible effect converts catastrophes into near-misses. Design for the delay where the stakes justify it.

References

• Confused deputy problem (Wikipedia)
• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide
• Anthropic's Responsible Scaling Policy