On a Tuesday morning in February 2026, an AI Governance Committee at a mid-cap European bank received a one-page memo from its Head of Internal Audit. "We have nineteen agents in production. Three of them can move money. All nineteen are configured with the same control set." The control set in question, a single OAuth service account, identical rate limits, the same approval gate, no kill-switch tier, was designed for a 2024-vintage research-assistant chatbot. The Head of Audit's conclusion was a single sentence: the controls fit the original agent and nothing else, and we have no defensible answer if the regulator asks why a customer-onboarding agent and a research summarizer share a privilege envelope. The fix isn't more controls. The fix is the right controls per tier. This lesson builds the four-tier autonomy control matrix, Suggest, Confirm, Act, Autonomous, that ties credential model, approval gate, blast-radius cap, kill-switch design, and audit-log granularity to the appropriate tier per agent action. Each tier is cross-walked to OWASP Agentic Top 10 (ASI03 Identity and Privilege Abuse, ASI06 Memory Poisoning, ASI10 Rogue Agents), MITRE ATLAS agentic techniques, and EU AI Act Article 14 human-oversight requirements. By the end you can produce the L3 deliverable: an autonomy-tier control matrix that an AI Governance Committee can defend to a market-surveillance authority and an internal auditor can use to score every agent in the portfolio.

Why One-Size-Fits-All Autonomy Controls Fail

The agentic shift between 2024 and 2026 collapsed the old assumption that "an AI system" is a chat interface with no side effects. By Q2 2026, the median enterprise AI portfolio contains a mix of pure-research assistants, drafting agents, tool-using agents with scoped credentials, and a small but growing number of long-running agents that act inside policy envelopes. The OWASP Agentic Top 10 (published in beta in 2024 and ratified for production reference in 2025) named ten attack classes that did not exist in the LLM Top 10, ASI01 Agent Goal Hijack, ASI02 Tool/Function Abuse, ASI03 Identity and Privilege Abuse, ASI04 Resource Manipulation, ASI05 Supply-Chain Compromise, ASI06 Memory Poisoning, ASI07 Inter-Agent Spoofing, ASI08 Repudiation and Untraceability, ASI09 Human-Agent Trust Exploitation, ASI10 Rogue Agents, and they all share a common property: the severity of any one of them depends on what the agent is allowed to do at the moment of compromise. A research assistant suffering ASI01 goal hijack produces a confusing summary; a customer-onboarding agent suffering the same hijack opens accounts.

The standard mistake is to apply a single control envelope across all agent action types. The two failure modes are symmetrical and equally common. Over-restriction applies the most paranoid control set (synchronous human approval per action; narrow read-only tools; no persistent memory) to every action, which cripples agent utility for routine drafting and research work and produces an organization that has agents but cannot use them. Under-restriction applies the loosest set (long-lived service account; no approval gate; broad tool catalog; no blast-radius cap) to every action, which creates an ASI03 + ASI10 exposure on the actions that genuinely need protection and a regulator-facing argument for which "the controls were designed for the research assistant" has no defense. The Acme bank memo above is the second failure mode. The 2026 fix is neither. It is to size the control envelope to the action.

The four-tier autonomy matrix is the artifact that does the sizing. Each agent action is classified into one of four tiers, Suggest, Confirm, Act, Autonomous, and each tier carries an explicit control set that scales with the blast radius of the action. The matrix is the unit of defensibility: when the regulator asks "why does the customer-onboarding agent have a different approval gate than the research assistant," the answer is "because they operate at different autonomy tiers, and here is the matrix." The same matrix is the unit of internal-audit testability: every agent in the portfolio is scored against the same rubric, every action mapped to a tier, every tier mapped to a control set.

The Four Autonomy Tiers - Suggest, Confirm, Act, Autonomous

The four tiers below are ordered by ascending autonomy and ascending blast-radius exposure. Each tier carries five control parameters that an AI Governance Committee can configure independently per action: credential model, approval gate, tool surface, blast-radius cap, kill-switch design. The audit-log granularity scales with the tier: Tier 1 logs the suggestion and the human action; Tier 4 logs every decision, every tool call, every parameter, every output, every anomaly with chain-of-custody attestation.

Tier 1 - SUGGEST (agent proposes; human executes)

At Tier 1, the agent does not act. It produces text: a summary, a draft, a recommendation, a candidate query. The human reads the output, decides what to do, and executes any action under the human's own identity. No agent credential is provisioned. No approval gate is needed because the agent has no action to approve. The tool surface is narrow: read-only retrieval (RAG against an internal knowledge base), compute-only operations (summarization, classification, drafting), and no write-access to any system of record.

• Credential model: No agent-acting credential. If the agent retrieves from a KB, the retrieval is scoped to information the requesting user is already authorized to read, and any service account is read-only with no write paths.
• Approval gate: Not applicable. The agent does not act.
• Tool surface: Read-only retrieval; compute-only operations (summarization, classification, drafting); no write tools, no payment tools, no destructive operations.
• Blast-radius cap: Bounded by the read-scope of the underlying retrieval, the agent can produce a bad summary, but cannot modify any record.
• Kill-switch: Not applicable at the agent level, the human is the action-taker. Disabling the agent is a UI-availability question, not a runtime-safety question.
• Audit log: Agent output (the suggestion); human action taken (accepted, edited, rejected, ignored). Granularity sufficient for Article 26(4) effectiveness monitoring and Article 14 oversight evidence.
• Use cases: Research assistant; meeting-summary generator; brainstorming aide; first-draft writer; classification suggester; KB-question answerer.
• Worked example: An agent reads the incoming email queue and suggests a reply for each. The user reviews each suggestion in their inbox; the user clicks Send when satisfied. The agent has no Send privilege. The action is the user's; the agent's contribution is text. ASI01 goal hijack produces a bad draft; the user reads it before sending.

Tier 2 - CONFIRM (agent prepares; human approves single step)

At Tier 2, the agent prepares an action. The action is parameterized, a specific resource, specific values, specific scope, and presented to the human for single-action approval. The human reviews, clicks approve, and the agent executes the single approved action. The agent does carry a credential (so it can execute the approved action), but the credential is short-lived, scoped narrowly, and useful only for the specific approved action.

• Credential model: Short-lived scoped credential. Typical pattern: a token valid for one hour, scoped to a single resource type, issued to the agent identity at session start and revoked on session end. The credential cannot be used to perform actions outside the session scope.
• Approval gate: Per-action approval. The human must click "approve" before each action executes; one approval = one action. The approval UI presents the action, its parameters, and the expected effect.
• Tool surface: Write-bounded, a defined set of write operations on a defined set of resource types, each gated by per-action approval.
• Blast-radius cap: One action per approval. Aggregate cap per session (e.g., 50 approvals per session before re-authentication). The human is the ceiling.
• Kill-switch: The human can decline approval; the decline is the effective kill of that action. Session-level revocation of the scoped credential is the agent-runtime kill.
• Audit log: Agent's proposed action and parameters; human's approval (or decline) with timestamp and identity; tool call and result. Three records per attempted action. Granularity supports Article 14 real-time oversight evidence.
• Use cases: Drafting and queuing actions for human approval. Email assistant that prepares a reply and presents it for one-click send. Calendar agent that drafts a meeting invitation and presents it for approval. Ticketing agent that drafts a JIRA ticket and presents it for submission. Procurement agent that drafts a purchase order and presents it for approval.
• Worked example: An agent prepares a meeting-invitation payload (attendees, subject, body, proposed times). The user sees the payload in the UI; the user clicks Approve; the agent sends the invitation via the calendar service. If the agent attempts to send a second invitation without a second approval, the gate refuses. If the credential expires mid-session, the next action prompts re-authentication. ASI01 goal hijack at Tier 2 produces a bad draft, the human reviewing the draft is the defense.

Tier 3 - ACT (agent executes within bounded budget)

At Tier 3, the agent executes actions without per-action approval, within an explicit bounded budget. The budget is the heart of Tier 3 design. It specifies the records, dollars, PII rows, and elapsed time the agent can touch in a session. Approval shifts from per-action to batched (the human reviews a summary every N actions or every X minutes) or threshold-based (the human approves only when a threshold is breached: anomalous tool call pattern, unexpected resource type, deviation from the policy envelope). The kill-switch is no longer a passive "human can decline". It is an active anomaly-detection circuit that pauses the agent on threshold trip.

• Credential model: Scoped credential with rate limits and resource bounds. Typical pattern: a credential valid for the session, scoped to a defined set of resource types, with rate limits enforced at the credential issuer (e.g., max 100 actions per hour; max 10 records per action; max $X spend authority per session). Credential is revocable mid-session by the kill-switch circuit.
• Approval gate: Batched approval (human reviews a summary every N actions or every X minutes) OR threshold-based (human is paged only when a threshold is breached). The summary review is sampling oversight; the threshold review is safety oversight; both are sized to support Article 14 effective oversight without becoming a per-action bottleneck.
• Tool surface: Write-broad within bounds. Transactional integrity preserved, every action is either fully applied or fully rolled back; partial state is not a permitted outcome. Destructive operations (delete, drop, truncate) require an additional confirmation gate or are disallowed at this tier.
• Blast-radius cap: Explicit and quantified. The control matrix specifies for each Tier 3 agent: maximum records touched per session; maximum dollars moved per session; maximum PII rows accessed per session; maximum elapsed time before forced re-authentication. These numbers are documented in the system card, presented to the AI Governance Committee at approval, and reviewed quarterly.
• Kill-switch: Anomaly threshold trip. The kill-switch is an automated circuit that pauses the agent and pages a human on any of: action outside policy envelope; tool call with anomalous parameters; rate-limit pattern deviation; PII access exceeding the documented cap; spend approaching the session ceiling. On trip, the agent pauses, the credential is revoked, and a human investigates within the documented response window (typically 15 minutes for Tier 3).
• Audit log: Every agent action with parameters, result, and any anomaly-detection signal; every credential issuance and revocation; every kill-switch trip and disposition. Granularity supports Article 14 sampling and safety oversight plus Article 73 incident-investigation evidence.
• Use cases: Agent processes routine helpdesk tickets within a category allowlist; agent sends batched status updates; agent manages inventory adjustments within a quantity cap; agent triages and assigns incoming support requests; agent reconciles routine accounting entries within a dollar cap.
• Worked example: An IT-helpdesk agent triages incoming Tier 1 tickets (password resets, software-install requests, access provisioning for pre-approved roles), assigns each to a queue, sends acknowledgment emails, and updates ticket status. The session budget is 200 tickets, $0 spend authority (no procurement actions), zero PII rows beyond what is already in the ticket payload. The kill-switch trips on: ticket category outside the allowlist (anomaly), ticket assignment outside the configured queues (anomaly), or aggregate-tickets-per-hour above 150 (rate anomaly). A human reviews a sampled 5% of resolved tickets the next morning and a full review of any kill-switch-tripped ticket within 15 minutes.

Tier 4 - AUTONOMOUS (agent acts within policy envelope)

Tier 4 is the highest-autonomy tier and, in May 2026, the rarest. At Tier 4, the agent acts independently within a policy envelope, there is no per-action approval and no batched approval; there is asynchronous review (a human reviews the agent's activity log periodically, daily, weekly, on cadence) and a hard kill-switch trip threshold. The credential is ephemeral; the agent obtains just-in-time credentials for each action and the credential window is measured in minutes. The kill-switch is unconditional on threshold trip. There is no human "approve to continue"; the agent stops, the credentials are revoked, and the incident-response process activates.

• Credential model: Ephemeral credentials. Typical pattern: 5-minute tokens; just-in-time provisioning per action class; credentials never persisted in agent memory; credentials cryptographically bound to the action class and resource scope. The credential lifecycle is auditable end-to-end (issuance, use, expiration, revocation).
• Approval gate: Asynchronous review. No per-action approval; no batched per-N approval. A human reviewer reads the agent's activity log on a defined cadence (typically daily for new Tier 4 deployments; weekly for mature deployments with established trust), and approves the continuation of the agent's operation at that review. Deviation from policy envelope is escalated within the review-cycle window with documented response time.
• Tool surface: Defined by the policy envelope; broad within the envelope. Tools outside the envelope are not callable, the policy envelope is enforced at the credential issuer (not just at agent-side validation), so even a compromised agent cannot escape the envelope without compromising the issuer.
• Blast-radius cap: Hard limits with hard kill-switch on threshold breach. The cap is documented in the system card and enforced both at the agent-side (request-time check) and the credential-issuer side (issuance-time check). Hard kill-switch trip thresholds are quantified (e.g., agent attempts an action outside envelope; agent's PII-access rate exceeds 110% of envelope; agent's spend rate exceeds 105% of envelope) and trip is unconditional.
• Kill-switch: Hard kill-switch on anomaly. Mandatory escalation on deviation, the kill-switch trip is reported to the AI Officer and to the AI Governance Committee within documented response windows (typically 1 hour for Tier 4); operation does not resume without explicit AI Governance Committee re-authorization and post-mortem completion.
• Audit log: Comprehensive with chain-of-custody attestation. Every credential issuance, every action, every parameter, every result, every policy-envelope check, every anomaly signal, every kill-switch trip with disposition. Log integrity protected with tamper-evident storage (e.g., append-only log with periodic hash anchoring). Granularity supports Article 14 bounded oversight defensibility plus Article 73 incident-investigation plus regulator-grade reconstruction of any specific action.
• Use cases: Rare in May 2026. Examples: long-running batch jobs with well-defined inputs and outputs (e.g., overnight log-anomaly classification with action set limited to "tag" and "escalate"); routine maintenance agents acting on pre-approved infrastructure within bounded change windows; specific high-value automation where the human reviewer cost is genuinely infeasible at scale and the mature-controls envelope is defensible to a market-surveillance authority.
• Worked example: An overnight infrastructure-monitoring agent classifies log anomalies into categories and either tags-for-morning-review or pages-on-call. The policy envelope: categories from a defined ontology; action set limited to "tag" and "page"; no destructive actions; no access to customer data; spend authority $0; aggregate page rate capped at 20 pages per shift. Credentials are ephemeral and issued per action. Kill-switch trips on: action class outside envelope, page rate above cap, attempted access to any non-log resource. A human reviews the activity log the next morning. Any kill-switch trip pages the on-call AI Officer within 1 hour and the AI Governance Committee at the next scheduled meeting.

Mapping to OWASP Agentic Top 10, MITRE ATLAS, and Article 14

Each tier carries a distinct risk profile against the OWASP Agentic Top 10 and a distinct oversight design under EU AI Act Article 14. The mapping below is what makes the matrix defensible to a regulator: the tier assignment is not a marketing label but a structured statement about which controls apply and which risks they mitigate.

ASI03 Identity and Privilege Abuse - Per-Tier Defense

• Tier 1: Minimal exposure, agent does not hold an acting credential. Read-only retrieval credentials are scoped to information already authorized to the requesting user; ASI03 abuse on a Tier 1 agent yields only read access, no write paths.
• Tier 2: Low exposure: credential is short-lived (1-hour), scoped to one resource type, and per-action approval gate prevents unauthorized use. ASI03 abuse on Tier 2 must escape the approval gate or compromise the credential issuer; both are auditable signals.
• Tier 3: Medium exposure, credential carries rate limits and resource bounds but persists for session duration; ASI03 abuse can ride the session credential for the session's duration. Mitigation: tight rate limits; kill-switch on anomaly; quarterly credential-issuance review; session-credential rotation.
• Tier 4: Highest defended exposure, ephemeral credentials minimize the abuse window per action, but the broader policy envelope and the absence of per-action human review mean an undetected ASI03 abuse can cause real damage between asynchronous reviews. This is why Tier 4 demands credential issuance bound to action class (so a stolen credential is usable only for that class), policy-envelope enforcement at the issuer (so escape requires issuer compromise), and hard kill-switch on any envelope deviation.

ASI06 Memory Poisoning - Per-Tier Defense

• Tier 1: Memory poisoning produces a bad suggestion; human review is the defense. Per-user memory hygiene (provenance tagging at write; cross-user pattern detection) remains baseline.
• Tier 2: Memory poisoning produces a bad draft; per-action approval is the defense. Same per-user memory hygiene as Tier 1; additional integrity check on any organization-wide memory partition.
• Tier 3: Memory poisoning can poison the agent's batched-action stream until the next anomaly trip. Mitigation: org-wide cache writes only from authorized pipeline (not from agent runtime); nightly integrity check; kill-switch trip on memory-content anomaly (e.g., suspicious pattern in retrieved memory).
• Tier 4: Most exposed, memory poisoning can ride asynchronously between reviews. Mitigation: org-wide memory writes prohibited from agent runtime entirely; per-action memory-content provenance check; memory-integrity check on every credential issuance; hard kill-switch on memory anomaly.

ASI10 Rogue Agents - Per-Tier Defense

• Tier 1: Negligible, rogue agent has no acting credential. Worst case: rogue produces bad suggestions which humans either accept or reject.
• Tier 2: Low, rogue agent must pass per-action human approval; the human reviewer is the defense. Mitigation: agent identity authenticated at credential issuance; suspicious-pattern detection on approval-request rate.
• Tier 3: Medium, rogue agent operating within the session credential can execute up to the rate-limit ceiling before kill-switch trips. Mitigation: identity binding of credential at issuance; SIEM correlation of agent runtime to credential use; kill-switch on rate anomaly.
• Tier 4: Highest exposure, a successfully-deployed rogue agent inside the policy envelope can cause real damage between reviews. The defense is layered: (1) agent identity authenticated cryptographically at every credential issuance, (2) policy envelope enforced at the issuer (rogue cannot exceed envelope without issuer compromise), (3) kill-switch design unconditional on any envelope deviation, (4) mandatory escalation on any deviation. This is why Tier 4 deployments are rare and demand AI Governance Committee approval per deployment.

MITRE ATLAS Agentic Techniques - Cross-Tier

The 2026 MITRE ATLAS additions for agentic deployments, AI Agent Context Poisoning, Memory Manipulation, Thread Injection, Modify AI Agent Configuration, RAG Credential Harvesting, Publish Poisoned AI Agent Tool, Escape to Host, all apply across all four tiers. The per-tier difference is in the blast radius of a successful technique. Context poisoning at Tier 1 produces a bad suggestion; context poisoning at Tier 4 can ride the policy envelope for hours. The matrix forces explicit recognition of this scaling and explicit design of detection and mitigation per tier.

Article 14 Human-Oversight Design Per Tier

EU AI Act Article 14 requires that high-risk AI systems be designed to allow effective human oversight. The article does not prescribe a single oversight modality. It requires that the oversight modality be appropriate to the system's intended use. The four-tier matrix is a structured way to defend the oversight modality to a market-surveillance authority:

• Tier 1 - Suggest: Human is the action-taker; oversight is inherent. Article 14 satisfied by definition (no agent action without human action).
• Tier 2 - Confirm: Per-action approval = real-time oversight. Article 14 satisfied by the approval gate; Article 26(3) reviewer-competence training is the supporting control; Article 26(4) effectiveness monitoring measured by per-action approval/decline rate, false-approval rate (post-hoc audit of approved actions that should have been declined), and approval latency.
• Tier 3 - Act: Batched approval (sampling oversight) + anomaly kill-switch (safety oversight) = layered oversight. Article 14 satisfied by the combination, not by either alone. The defensibility argument requires both, sampling without safety leaves anomalies unaddressed; safety without sampling leaves systematic drift undetected. Article 26(4) effectiveness measured by sample-review false-negative rate, kill-switch trip rate, kill-switch false-positive rate, and time-to-investigation on trip.
• Tier 4 - Autonomous: Async review + hard kill-switch + mandatory escalation = bounded oversight. Article 14 defensibility under Tier 4 is the hardest and requires (a) the policy envelope to be narrow enough that the asynchronous review can meaningfully detect deviation, (b) the kill-switch trip thresholds to be tight enough that any meaningful deviation trips before damage exceeds remediation capacity, (c) the escalation path to be operationally proven (tabletop exercises quarterly), and (d) the AI Governance Committee approval per Tier 4 deployment with documented justification for why a higher-tier oversight modality is not feasible. The committee approval is the defensibility artifact when the regulator asks "why is asynchronous oversight sufficient here?"

Worked Portfolio - Two Agents Through the Matrix

The matrix is most useful applied. Two worked examples below: a routine internal IT-helpdesk agent (Acme.HelpdeskAgent v1.0) and a customer-facing order-processing agent (Acme.OrderProcessingAgent v0.5). Each agent has multiple action types; each action type maps to a tier; the tier determines the control set.

Acme.HelpdeskAgent v1.0: Tier Map

• KB lookup, summarization, draft-reply generation-Tier 1 SUGGEST. Read-only retrieval; agent produces text; human (the Tier 1 helpdesk reviewer) takes the action. Credential: read-only KB service account; no acting credential. Approval: none. Kill-switch: not applicable.
• Create ServiceNow ticket on behalf of user-Tier 2 CONFIRM. Agent drafts the ticket payload; user reviews; user clicks Submit; agent submits the single ticket. Credential: short-lived scoped to ServiceNow ticket-create. Approval: per-action. Kill-switch: user declines = effective kill.
• Password reset on user's own account-Tier 2 CONFIRM. Agent initiates; MFA second-factor by user; agent executes the reset. Credential: short-lived scoped to AD password-reset on the requesting user's account. Approval: per-action via MFA gate. Kill-switch: MFA decline = kill.
• Routine ticket triage and queue assignment (Tier 1 ticket categories only)-Tier 3 ACT. Agent triages incoming tickets, classifies into pre-approved categories, assigns to queues, sends acknowledgment emails. Session budget: 200 tickets, $0 spend, zero PII beyond the ticket payload. Credential: session-scoped to ServiceNow read/update on triage-eligible tickets, rate-limited to 60 actions/minute. Approval: batched (5% sample reviewed next morning). Kill-switch: ticket category outside allowlist, queue outside allowlist, rate above 150/hour.
• Tier 4 actions: None in v1.0. Future Q3 2026 candidate: overnight status-update bulk operation for already-resolved tickets, gated on AI Governance Committee review of the policy envelope.

Acme.OrderProcessingAgent v0.5, Tier Map

• Customer-query response drafting-Tier 1 SUGGEST. Agent reads the inbound query, drafts a response; CSR reviews and sends. Credential: read-only to order-system and KB; no send credential.
• Order-modification request preparation-Tier 2 CONFIRM. Agent prepares the modification payload (e.g., shipping-address change); CSR reviews and approves; agent submits the single modification. Credential: short-lived scoped to order-system modify on the specific order ID. Approval: per-action.
• Routine order-status updates and shipping-confirmation sends within session budget-Tier 3 ACT. Agent updates order status from the carrier feed, sends confirmation emails to customers. Session budget: $1,000 refund authority per session, 500 status updates per session, no PII access beyond the order payload, no payment-method modification. Credential: session-scoped to order-system update on confirmed-shipped orders only, rate-limited to 100 actions/minute. Approval: batched (10% sample reviewed within 4 hours). Kill-switch: refund amount above $50 per order, refund aggregate above $1,000 per session, attempted payment-method modification (always disallowed), attempted access to non-shipping PII fields.
• Overnight batch-close of confirmed-delivered orders (older than 14 days, no open issues)-Tier 4 AUTONOMOUS. Agent runs nightly, closes confirmed-delivered orders past the 14-day window with no open issues, updates inventory counts. Policy envelope: action set limited to "mark closed" and "decrement inventory count"; no refunds; no payment-method access; no customer-PII writes; spend authority $0; aggregate cap 10,000 orders per night. Credentials: 5-minute ephemeral per action class. Approval: asynchronous (daily review by Operations team next morning). Kill-switch: any action outside envelope; aggregate above 10,000; attempted access to refund or payment-method tools; any inventory decrement above 20% of stock on any SKU. Mandatory escalation on trip; AI Governance Committee re-authorization required to resume after any trip.

The Acme.OrderProcessingAgent v0.5 example shows the disciplined use of Tier 4: narrow envelope, hard caps, ephemeral credentials, comprehensive logging, asynchronous review with documented response windows, hard kill-switch. The Acme.HelpdeskAgent v1.0 has no Tier 4 actions because the AI Governance Committee judged that the marginal value of Tier 4 automation in the helpdesk context did not justify the Tier 4 oversight overhead at v1.0. Tier 4 is not a milestone; it is a deliberate design decision per action.

Cross-Walks and Common Mistakes

The autonomy-tier control matrix is a single artifact that serves multiple frameworks at once. The cross-walks below are the framework windows on the same matrix; the common-mistakes list is the failure modes the matrix is designed to prevent.

Cross-Walks - One Matrix, Multiple Frameworks

• EU AI Act Article 14: Each tier's approval-gate and kill-switch design is the documented Article 14 human-oversight measure for the actions in that tier. Tier 1 = inherent oversight; Tier 2 = per-action; Tier 3 = sampling + safety; Tier 4 = bounded with hard kill-switch.
• OWASP Agentic Top 10: ASI03/ASI06/ASI10 per-tier defense documented explicitly; ASI01/ASI02/ASI04/ASI05/ASI07/ASI08/ASI09 mitigations apply with per-tier scaling (e.g., ASI04 resource-exhaustion bounded by rate limits; ASI08 untraceability defeated by tier-appropriate audit-log granularity).
• MITRE ATLAS: Agentic-technique detection and mitigation scaled per tier; same techniques apply, blast radius scales with tier.
• NIST AI RMF: Govern 1.4 (operating context), the tier assignment is the operating-context decision per action; Map 5 (impact characterization), tier informs blast-radius assessment; Measure 1 + 2, per-tier effectiveness metrics; Manage 1 + 4, per-tier prioritization and response.
• NIST AI 600-1: Risk 10 (information security), per-tier credential and identity design; Risk 11 (value chain), per-tier supplier and integration trust assumptions; Risk 12 (harmful bias), per-tier review cadence catches drift.
• ISO/IEC 42001:2023: A.6.1.1 (impact assessment), per-action tier assignment is the impact-assessment output; A.6.2 (impact criteria): per-tier credential, approval, kill-switch, blast-radius cap, log granularity are the criteria; A.6.4 (post-deployment monitoring), per-tier sampling and kill-switch metrics are the monitoring evidence; A.8 (information for users), per-tier disclosure in system card.
• CAISI Agent Standards Initiative (NIST CAISI working group, 2025-2026): Tier-classification framework consistent with CAISI emerging guidance; matrix structure aligned with the Initiative's draft autonomy taxonomy.
• NIST AI Agent Interoperability Profile (planned Q4 2026): Anticipated alignment of tier-tagging with cross-agent interoperability metadata; the matrix is forward-compatible with the planned profile structure.

Six Common Mistakes in Autonomy-Tier Control Matrices

1. One-size-fits-all autonomy, Treating "the agent" as a single thing with a single tier. Agents have multiple action types; the matrix is per action, not per agent. The Acme.HelpdeskAgent example above shows the same agent operating at Tier 1, Tier 2, and Tier 3 simultaneously for different action types.
2. Weak Tier 3 blast-radius cap, "Acts within bounded budget" without quantifying the bound. The cap must be explicit: records, dollars, PII rows, elapsed time. "Bounded" without numbers is not defensible to an auditor or a regulator.
3. Missing or untested kill-switch design, Documenting a kill-switch and never testing it. The kill-switch must be tested quarterly (tabletop or live), with documented expected behavior and documented actual behavior. An untested kill-switch is an unproven control.
4. Weak credential scoping at Tier 4, "Ephemeral credentials" without binding to action class. A 5-minute credential that is usable for any action class is still a 5-minute window of broad authority. Tier 4 demands credential cryptographically bound to action class and resource scope so a stolen credential is usable only for the action the agent legitimately invoked.
5. Audit-log granularity mismatched to tier, Tier 4 with Tier 1 logging is undefensible. The log granularity must scale with the tier: Tier 1 logs suggestion + action; Tier 4 logs everything with chain-of-custody attestation. Mismatch means a regulator cannot reconstruct the agent's behavior and the deployer cannot defend the oversight modality.
6. No quarterly refresh of tier assignments, Assigning tiers at deployment and never revisiting. Action types change as features ship; new tools added; existing tools' scope changes; new threats emerge; new regulator guidance lands. Quarterly review of tier assignments, and triggered review on tool catalog change, base-model version change, new feature ship, OWASP/ATLAS update, red-team finding, is the only way to keep the matrix accurate.

Key Takeaways

• The four-tier autonomy control matrix, Suggest, Confirm, Act, Autonomous, sizes the control envelope to the action, not to the agent. Each action in an agent's catalog maps to a tier; the tier determines credential model, approval gate, tool surface, blast-radius cap, kill-switch design, and audit-log granularity.
• Tier 1 SUGGEST: no agent credential, no approval gate, narrow read-only/compute-only tool surface; human is the action-taker; Article 14 oversight inherent.
• Tier 2 CONFIRM: short-lived scoped credential, per-action approval gate, write-bounded tool surface; agent prepares, human approves single step; Article 14 oversight real-time.
• Tier 3 ACT: scoped credential with rate limits and resource bounds, batched or threshold-based approval, write-broad within bounds, explicit blast-radius cap (records / dollars / PII rows / elapsed time), automated kill-switch on anomaly; Article 14 oversight = sampling + safety.
• Tier 4 AUTONOMOUS: ephemeral credentials bound to action class, asynchronous review, broad-within-envelope tool surface, hard limits with hard kill-switch on any envelope deviation, mandatory escalation; Article 14 oversight = bounded, defensible only with narrow envelope, tight kill-switch thresholds, and AI Governance Committee per-deployment approval.
• OWASP Agentic Top 10 ASI03/ASI06/ASI10 defense scales per tier. ASI03 exposure is minimal at Tier 1 and highest defended at Tier 4; ASI06 defense relies on memory hygiene at all tiers with progressively stricter pipeline controls at Tier 3/4; ASI10 defense layers identity authentication, policy-envelope enforcement, and kill-switch design with the strongest layering at Tier 4.
• MITRE ATLAS agentic techniques apply across all tiers; the blast radius of a successful technique scales with the tier. The matrix forces explicit detection and mitigation design per tier.
• The matrix is per-action, not per-agent. The Acme.HelpdeskAgent operates simultaneously at Tier 1 (KB drafting), Tier 2 (ticket create, password reset), and Tier 3 (routine triage). The Acme.OrderProcessingAgent adds Tier 4 (overnight close batch) with disciplined envelope and hard kill-switch.
• Tier 4 is rare in May 2026. It demands AI Governance Committee per-deployment approval, narrow policy envelope, ephemeral credentials bound to action class, hard kill-switch on any envelope deviation, mandatory escalation, and comprehensive audit logging with chain-of-custody attestation.
• The matrix is a single artifact serving multiple framework windows simultaneously. EU AI Act Article 14 + OWASP Agentic Top 10 + MITRE ATLAS + NIST AI RMF Govern/Map + NIST AI 600-1 + ISO 42001 A.6/A.8 + CAISI Agent Standards Initiative + NIST AI Agent Interoperability Profile (planned Q4 2026).
• Quarterly refresh of tier assignments, triggered by tool catalog change, base-model version change, new feature ship, OWASP/ATLAS technique update, red-team finding, or regulator guidance change, is the only way to keep the matrix accurate. A static matrix from deployment time is stale within a quarter.