The Security Autonomy Matrix is a framework for deciding how much authority to grant your security AI agents, one kind of action at a time. You record those decisions in one table, one row per workflow, capturing the autonomy level, who answers for it, and when the grant expires.
Cybersecurity teams are increasingly adopting AI technologies for their workflows. How should they decide what authority to grant their AI agents, and how independently the agents may exercise it? The Security Autonomy Matrix is an approach to making these decisions and capturing them in one table. Each row in the table represents a security workflow. It records the five decisions we make about that workflow. By capturing decisions this way, we can enforce them through our tooling, widening the AI’s autonomy as it earns trust.
This is my initial version of the Security Autonomy Matrix. I’d love to hear your feedback.
This guide is also available as PDF and Word documents, so you can read it offline or share it with others.
Contents:
- Keep a record of AI authority decisions
- Decide how much autonomy each AI action gets
- Put the Security Autonomy Matrix to work
- What the matrix is based on, and what is new
- Thank you to the reviewers
Keep a record of AI authority decisions.
Like every executive in the organization, security leaders are looking for responsible ways to deploy AI within their functions. Getting the most out of AI often means granting it agentic capabilities, so it has the authority to make security decisions and take security actions on its own. How does a leader grant that authority deliberately and responsibly?
Consider an AI agent that removes the phishing messages that reached user mailboxes. The agent can read every mailbox safely, yet one wrong deletion can permanently remove a legitimate message. Security leaders need to decide, for this and other security workflows, whether to allow the agent to make the call and take the action.
Deciding how much authority to grant AI is a leadership judgment, and there is little established guidance. In the 2026 SANS AI Survey, only 41% of organizations reported using generative AI for security-related tasks under strict policy. Another 39% said usage is informal, with no policy at all.
Security teams need a single place to capture what they have allowed AI agents to do on their own. The Security Autonomy Matrix is that record. Without it, a team has to reconstruct what its AI may do from tool settings, runbooks, and the memory of whoever set them up. Instead, as security leaders, we can capture those decisions in the matrix, with one row per security workflow: the permissions granted, the accountable person, and what reopens the decision.
What is the Security Autonomy Matrix?
The Security Autonomy Matrix is a table with a row for each security workflow where AI performs actions whose mistakes would be costly or hard to reverse. One column identifies the workflow, and the other five each record a decision security leaders make about it:
- Autonomy: How independently the AI may act. Set it separately for each kind of action in the workflow, such as reading data, sending email, or deleting records.
- Accountable person: The person who answers for the AI’s actions.
- Gate: The point where a person approves, overrides, or rolls back the AI’s action.
- Residual risk: The harm that remains possible and the safeguard that limits it.
- Reevaluation trigger: The events that reopen the autonomy decision, and the date when the row expires.
Add a row for every workflow where the AI performs actions whose mistakes would be costly or hard to reverse. This includes workflows where a person still approves each action, and workflows where you’re only considering such autonomy.
Authority specifies what the AI agent may do. Autonomy is how independently it may exercise that authority. The row’s Autonomy column captures both the kinds of actions the AI may take in the workflow and how independently it may take each. I named the matrix for autonomy because the autonomy level is the central decision in each row.
The matrix captures decisions so you can enforce them.
The Security Autonomy Matrix is an authorization policy for non-human workers. OWASP’s Top 10 for Agentic Applications prescribes narrow permissions for AI agents, including “read-only queries for databases, no send/delete rights for email summarizers.” A leader using the matrix grants authority the same way, deciding separately what the AI may read, send, or delete. SANS’s Critical AI Security Guidelines prescribe the same discipline: “clearly delineated permissions” for each agent, and human oversight for any “critical operations” it can reach. The matrix is where a leader decides which operations those are, who answers for the decision, and what reopens it.
Because the matrix is policy, it needs an owner and a place in the program. The security leader owns it like the rest of the security policy. Each row needs enforcement, whether through the tooling’s permission settings or through a manual check where the tooling falls short. Security teams already run access reviews for least privilege and grant policy exceptions with expiration dates, and the matrix records the same discipline for the authority they grant their AI. A team can adopt the matrix even before those broader practices mature, starting with a few rows.
The Security Autonomy Matrix can record the five decisions for any AI agent in the enterprise, whether the agent screens résumés or pays invoices. This guide covers security workflows. To apply the matrix in another business function, keep the same columns and fill the rows with that function’s workflows.
Decide how much autonomy each AI action gets.
A leader sets the AI’s autonomy level for each kind of action, such as reading data or deleting records. This involves considering the cost of a mistake in that action and whether someone can undo it. The Security Autonomy Matrix describes autonomy using five levels, ranging from a person doing all the work to AI acting on its own with after-the-fact audits.
A leader can keep costly, irreversible actions behind a person’s approval and leave the low-cost, reversible ones to the AI.
Define AI autonomy in five levels, the way driving automation does.
The five autonomy levels in the Security Autonomy Matrix are an adaptation of the SAE driving-automation levels, familiar from self-driving cars:
| Level | Name | Meaning |
|---|---|---|
| L0 | Manual | A person does all the work. AI is not involved. |
| L1 | Advisory | AI recommends and drafts. A person performs every action, so nothing the AI produces takes effect on its own. |
| L2 | Supervised | AI performs the action. A person approves each one before it takes effect. |
| L3 | Conditional | AI acts within set limits. A person handles exceptions and escalations. |
| L4 | Independent | AI acts on its own. A person reviews by audit, after the fact. |
The biggest jump in what the AI does is from L1 to L2, where it starts performing actions. At L0 and L1, a person performs every action, and the AI at most advises. From L2 up, the AI acts, and the remaining question is when a person checks its work. A person approves each action in advance at L2, handles exceptions at L3, and audits after the fact at L4. The biggest jump in authority is from L2 to L3: that is the first level where the AI acts without a person approving each action.
Industry analysts and security researchers also describe AI autonomy in levels. Gartner recommends classifying AI agents “across distinct autonomy levels, with each level representing a different trust boundary.” Ahmad Mohsin and colleagues reached a similar conclusion, structuring SOC autonomy into five SAE-inspired levels. Jim Reavis, CSA’s co-founder, proposed six SAE-inspired levels for agentic AI and asked whether a single system “might warrant Level 3 autonomy for some actions and Level 1 for others.” That convergence is the reason to build the matrix on these five levels. Among this framework’s additions are the five kinds of action and the five-column decision record, covered in the next section. Setting a separate level for each kind of action answers Jim’s question: one agent can read on its own while a person approves everything it deletes.
Each kind of action gets its own autonomy level.
One way to think about the AI’s actions is to group them into five classes. The classes differ in the cost of a mistake and whether it can be undone. That difference is why each class needs its own autonomy level:
| Class | What the AI may do | Why the class gets its own autonomy level |
|---|---|---|
| Read | Query data, such as logs, tickets, and mailboxes | A wrong read changes nothing, though broad access can expose sensitive data |
| Write | Change the state of something the AI already has authority over, where the AI can put that state back in the same system without a saved copy, such as editing a ticket, isolating an endpoint, or disabling an account | Wrong writes are recoverable, at a price, once someone notices them |
| Send | Communicate beyond the team, such as emailing a user or replying to an outside researcher | No one can unsend a message |
| Spend | Commit resources, such as money, API credits, or cloud quota | An agent can spend a budget before anyone looks |
| Delete | Remove something, or destroy state that comes back only from a saved copy or by building it again, such as removing a firewall rule, terminating a running process, or purging mail | A wrong delete may be permanent |
A single AI agent can hold a different autonomy level for each class of action. Each combination of class and level is a grant. A leader might let an agent read logs on its own at L4 (Independent) while requiring that a person approve everything it writes, sends, spends, or deletes. Some of the products our agents connect to already separate these permissions. Outlook grants Send apart from read and write, and its read-write permission “does not include permission to send mail.” Gmail offers a send-only scope, though its broader scopes bundle sending with reading.
Granting autonomy separately for each kind of action is an idea with a long track record. In 2000, Raja Parasuraman, et al. proposed four classes of automatable functions and observed that automation within each class can apply “across a continuum of levels.” Their classes describe stages of information processing; the matrix’s classes describe the authority a leader grants and revokes. The closest current counterpart to the matrix’s classes is the Cloud Security Alliance’s multi-dimensional enhancement of AWS’s Agentic AI Security Scoping Matrix, which splits data operations into “read vs. write” for the engineers who secure AI agents.
Classify one operation at a time.
Send and Spend are easy to classify. The AI performs a Send when it communicates with anyone outside the team that runs the agent. Customers, vendors, and outside researchers all sit outside that team. The AI performs a Spend when it commits money, credits, or quota.
Telling a Write from a Delete comes down to what the AI can put back by itself. Write down every change the action makes inside the system the AI is acting on. For each change, ask whether the AI can undo it in that same system, using the authority you already granted. When the AI can undo every change, the action is a Write. When the AI cannot undo even one change, the action is a Delete. Restoring from a backup, a journal, or a quarantine store does not count, because someone saved that copy ahead of time.
For example, when the AI isolates an endpoint, it cuts that machine off the network and changes nothing else. The AI can reconnect the machine in the same endpoint product, so isolation is a Write. When the AI purges a mailbox, the mail is gone, and only a saved copy brings it back. Purge is a Delete, and the quarantine you keep is that saved copy.
Classify actions by the authority you grant, not by the safeguard you happen to run. Quarantine makes a wrong purge survivable. Record it as a safeguard, note the risk that remains, and leave the class alone. If safeguards could change classes, any team could reclassify a dangerous action by bolting recovery onto it. The row would then stop saying what the AI may do. On the day a quarantine is misconfigured or its retention has lapsed, the action was a Delete all along.
Work through the harder cases.
A first glance puts these three actions in the wrong class:
- Killing a process: The AI stops the service that process was running and destroys whatever was in the process’s memory. The service manager starts the service again, and nothing brings the memory back, so killing a process is a Delete. That stays true whether the process was a stuck web server or a program you suspect an attacker planted.
- Quarantining a file: The AI removes the file from where it was, and getting it back means pulling the saved copy out of the quarantine store, which the endpoint product deletes after a set number of days. Quarantining a file is a Delete, while isolation stays a Write because the AI reconnects the endpoint directly, with no saved copy involved.
- Granting a permission: The AI adds a permission for someone and can remove it in the same system, so granting is a Write. Removing it does not undo what that person did while they held it. Record that in the residual risk cell.
You can grant the same Delete at different levels in different workflows. Give it a high level in a workflow that restarts stuck services, because nothing worth keeping was in that memory. Keep it low in a workflow that kills suspicious programs, because that memory may be the only evidence you have.
Three more rules cover drafting, combined actions, and code:
- Message drafting: Set Send at L1 (Advisory) when you want the AI to draft messages that a person sends, and reserve Send L0 (Manual) for workflows where the AI should play no part in the message.
- Combined actions: When one action spans multiple classes, use the lowest of their autonomy levels. An action that changes a system and also notifies a third party is both a Write and a Send. If the row records Write at L3 (Conditional) and Send at L2 (Supervised), that combined action needs a person’s approval. This rule covers a command that performs two operations you could have granted separately. When a single operation changes several things at once, place it with the test above.
- Code and playbooks: Classify running code by its effects, whether the AI runs a script or triggers a playbook, a prewritten set of automated steps. A script that reads files, sends email, and deletes records falls under the Read, Send, and Delete grants at once. When you can’t predict the code’s effects, hold every class it could touch at L2 (Supervised), and have a person inspect and approve each run.
Gate the actions that have no undo.
The gate is the checkpoint where a person approves the AI’s action in advance, overrides it while the action is underway, or rolls it back afterward. It’s captured in a dedicated Gate column of the matrix. Decide which actions need the gate by weighing two measures:
- Blast radius: How much damage a wrong action could cause, from a single user to the whole business.
- Reversibility: Whether you can undo the action faster than the damage spreads.
Blast radius and reversibility are judgments you make per workflow. For example, disabling a lab firewall rule might inconvenience a few engineers, while disabling a production rule might affect customers. When estimating the blast radius, also weigh how much data the AI can access and what it would reveal, since a single misstep could expose many sensitive records. Reversibility varies the same way: you can restore a quarantined file, but not a hard-deleted one.
Irreversible AI actions require the same caution as irreversible business decisions. Jeff Bezos referred to such decisions as “one-way doors” in his 2015 letter to shareholders. A one-way door is a decision you cannot undo, and a two-way door is one that you can. He urged slow deliberation at one-way doors and speed through two-way doors. Let the AI take the reversible actions on its own, and require a person’s approval when you cannot undo the damage faster than it spreads.
When the AI reads untrusted content, such as inbound email or web pages, an attacker can hide instructions within it to trick the agent into taking malicious actions (prompt injection). The hidden instructions can trigger any action the agent can take on its own, not just a Send. In such workflows, set every class whose mistake would be costly or hard to reverse to L2 (Supervised) or lower. If a grant must stay higher, tighten its limits instead, such as the destinations the agent can reach, the systems it can change, or the amount it can spend. Write the safeguard and the remaining risk into the row’s residual risk cell.
Read needs its own safeguard against prompt injection. A wrong read changes nothing, so you might reasonably leave Read at a high level. Yet injected instructions can make the agent read data the workflow never needs, through queries it was authorized to run. At L3 (Conditional) or higher, no person approves each query, so the exposure depends on what the agent can see, whether one ticket queue or every mailbox in the company. Narrow the Read grant to the data the workflow needs, and weigh what the agent can still reach as part of the row’s blast radius.
You can often raise an action’s autonomy level by making the action reversible. Recall the agent that removes phishing messages from user mailboxes. Route its removals through a recoverable quarantine instead of hard deletes, and an administrator can restore a message the AI got wrong. The leader can then let the AI handle routine removals on its own.
People add the most value before and after the AI’s work.
As AI absorbs routine security work, people can focus on direction, judgment, and accountability. Daniel Miessler argues that much of knowledge work is scaffolding, the routine steps between decisions, and that AI strips those steps away, leaving the judgment behind. That distinction between scaffolding and judgment is a practical test of where people fit in a workflow.
To decide where people fit in a workflow, work backward from what your AI already handles well to the parts that still need a person. Check the two ends of the workflow first: the direction set before the AI starts, and the judgment applied to its output afterward. Record the actions a person must approve at L2 (Supervised), the exceptions a person handles at L3 (Conditional), and the actions a person reviews after the fact at L4 (Independent).
Put the Security Autonomy Matrix to work.
Your first working Security Autonomy Matrix can be as small as two or three rows that record the authority that AI already holds. Copy the following one-table template and fill those rows in. Then revisit the table periodically, raising and lowering autonomy levels when the accountable person has evidence for a change.
Give every grant an expiration date and require the accountable person to reevaluate the grant based on the AI’s track record for that workflow. Build that track record from logs of the AI’s activity. When the AI misbehaves, your team can investigate what exactly happened from the same logs. Watch a few metrics to see whether the practice is working, such as overdue renewals and mismatches between the recorded grants and the enforcement in place.
Copy the blank template and fill in your first row.
Copy this blank table to start your own Security Autonomy Matrix:
| Workflow | Autonomy by action class | Accountable person | Gate | Residual risk and safeguard | Reevaluation trigger and expiration |
|---|---|---|---|---|---|
Fill in the columns this way:
- Workflow: Outline the security workflow where the AI performs actions whose mistakes would be costly or hard to reverse. Give it a name, and record the event that starts the workflow, such as a person’s request, a schedule, or a detection. This column identifies the workflow. The other five each record a decision.
- Autonomy by action class: Record the AI’s current autonomy level (L0 to L4) for each class of action in the workflow: Read, Write, Send, Spend, Delete. Record L0 (Manual) where the action happens but the AI plays no part, and omit a class only when that action never occurs in the workflow. For a grant at L3 (Conditional), record when the AI may act and how far it may go, such as, “The agent may isolate up to five workstations on its own when a high-confidence detection fires.”
- Accountable person: Record the name and title of the person who answers for the AI’s actions. Others may run the workflow day to day, but this person decides whether to renew, promote, or demote each grant. Tie accountability to the role, so the next person in the role takes it on when people change jobs.
- Gate: Record which actions a person should approve in advance, override, or roll back, and name who can do each. Decide by weighing how much damage a wrong action could cause and whether someone can undo it. For a grant whose only check is an after-the-fact review, record who should review the AI’s actions and how often.
- Residual risk and safeguard: Describe the harm that can still happen even with the gate in place, and the safeguard that limits it. State the harm in concrete terms, such as downtime, data exposure, financial loss, or a regulatory obligation. When the grant comes up for renewal, the accountable person has to decide whether the risk is still worth accepting, and after an incident, whether the safeguard worked.
- Reevaluation trigger and expiration: List the events that should reopen a grant, whether as grounds for more autonomy or less. When the event is something the AI itself does, define it as a signal your team can spot in the AI’s activity logs, such as false isolations or disputed answers counted over a quarter. Then add the date when the row expires and its grants come up for renewal together. That date can be the row’s own or the default expiration you set for the whole matrix.
Review a sample matrix with example rows.
A fragment of a Security Autonomy Matrix might look like this, with invented values and the accountable people listed by role alone. Each Autonomy cell names an action class, its level, and, in parentheses, the specific action the AI takes in that workflow:
| Workflow | Autonomy by action class | Accountable person | Gate | Residual risk and safeguard | Reevaluation trigger and expiration |
|---|---|---|---|---|---|
| Vendor security questionnaires (a customer’s request) | Read L4 · Write L2 (writes draft answers into the response) · Send L1 | Governance, risk, and compliance (GRC) lead | A person reviews and sends every response | The reviewer could miss a wrong claim and send it to a customer, so answers draw on an approved library | Two disputed answers are the signal to pull Write back to L1, or a clean quarter is grounds to raise Send to L2. Default expiration |
| Stale firewall rule cleanup (a monthly schedule) | Read L4 · Write L3 (turns off rules unused for 90 days) · Delete L2 | Network security lead | An engineer approves each permanent removal | The AI could turn off a rule an application depends on and break it. Every removal starts as a disable, with the old rule kept for restore | The first outage traced to a cleanup is the signal to pull Write back to L2, or two clean quarters are grounds for Delete L3. Expiration: six months |
| Bug bounty triage (a researcher’s submission) | Read L4 · Write L3 (labels reports and closes exact duplicates) · Send L2 (replies to researchers) · Spend L1 (recommends award amounts) | Product security lead | A person approves each researcher reply, and a person decides and pays every award | The AI could close a real report as a duplicate, so a person samples closed duplicates weekly | A buried report is the signal to pull Write back to L2, or a clean quarter of sampled duplicates is grounds to raise Write to L4. Default expiration |
| Endpoint isolation (a detection) | Read L4 · Write L2 (isolates hosts) | Security operations center (SOC) manager, with an on-call incident response (IR) lead after hours | An analyst approves each isolation, and the IR lead approves any server or more than five workstations | The AI could isolate a machine the business depends on, so every isolation triggers a page to the on-call lead, and the help desk can release a wrong one in minutes | Two false isolations in a quarter are the signal to hold Write at L2 or return it there, and a quarter of accurate isolations is grounds for Write L3, limited to high-confidence detections and five or fewer workstations per incident. Default expiration |
Here is the firewall cleanup row, one column at a time:
- Autonomy by action class. The AI takes two kinds of action in this workflow, and they differ in what a mistake would cost, so each kind gets its own level. Turning a firewall rule off is reversible because someone can turn it back on. The AI may do that on its own, a Write at L3. Deleting a rule for good is permanent, so a person has to approve each deletion, a Delete at L2.
- Accountable person. The network security lead answers for this workflow. Typically, you’d also list the person’s name, but ensure that the responsibility stays with the role across personnel changes.
- Gate. In this workflow, the organization decided that only the permanent removals need a person’s approval. An engineer has to approve each one before it happens, and the AI may turn rules off on its own.
- Residual risk and safeguard. The harm that could still happen is that the AI turns off a rule that an application depends on. The safeguard is to remove rules in two steps: the AI first turns a rule off but keeps it, so anyone can turn it back on if that breaks something, and only later does a person delete it for good.
- Reevaluation trigger and expiration. Two kinds of events can reopen this row’s decisions. An outage traced to a cleanup is the signal to pull the AI’s Write grant back to L2. Also, two quarters without any cleanup-related outages or incorrect deletions are grounds for raising Delete to L3. The row expires every six months, because the team can gather rule-cleanup evidence fast enough to reevaluate the grants on that schedule.
Endpoint isolation works differently from the other rows, because the workflow starts with a detection rather than a person’s request, and the organization expects a machine-speed response. The sample row shows how the AI can earn the autonomy for that speed:
- Today: Write sits at L2 (Supervised). An analyst approves each isolation before it happens.
- The promotion path: The row’s Reevaluation cell shows that a quarter of accurate isolations is grounds for raising Write to L3 (Conditional), limited to high-confidence detections and five or fewer workstations per incident.
- After the promotion: A detection would still start the workflow, but the AI would isolate on its own only when the detection meets those limits. It could contain a routine intrusion the moment the detection fires, and anything wider, such as a server or a sixth workstation, would still need the incident response lead’s approval.
This is how a leader can grant machine speed safely: the AI earns the promotion with its track record. The limits written into the grant spell out when the agent may act and how far it may go. When you can’t limit an action this tightly or undo it quickly, keep it at L2, behind a person’s approval.
Rob Fuller’s Standing Authority Matrix is a table of machine-speed actions built on the same idea as the endpoint promotion: autonomy pre-approved within recorded limits. It lists actions that are “small and reversible by design,” each with a named approver and a documented rollback path. An action either qualifies for the matrix and runs on its own or stays behind a human gate. The Security Autonomy Matrix applies that discipline to any security workflow. Between an action the AI takes on its own and one a person handles, it accommodates the full range of autonomy, from L0 to L4.
Autonomy is earned, and it can be taken back.
An AI agent can earn expanded authority the way a medical resident earns unsupervised procedures: by performing under supervision first. Residency programs have run this model for decades, providing “increasing autonomy as residents progress through training,” a principle known as graded responsibility. The sample endpoint isolation row records the same principle in its promotion path.
Leaders can also pull autonomy back, according to the conditions written into the row as its reevaluation trigger. After repeated false containment actions, you would lower the affected grant to a human-approval gate until its track record supports raising it again. Bala Priya C states the principle in a DevOps.com essay, “Autonomy is a consequence of demonstrated reliability, not a starting assumption.” Josh Woodruff’s Agentic Trust Framework describes the same discipline per agent, with promotion gates and automatic demotion. Only the accountable person may grant more autonomy, however strong the track record.
A significant change to the AI agent’s model or version should also reopen the decision. The agent earned the grant under the old model and might behave differently under the new one.
Every grant expires.
Every grant needs an expiration date, as security policy exceptions do. Reevaluation triggers depend on someone noticing an event, and expiration reopens the decision on schedule. Handle expiration this way:
- What expires: The whole row at once. The default expiration reopens all the row’s grants together. An event in the row’s Reevaluation trigger can still reopen a single grant on its own.
- What happens when a row expires: Grants above L2 (Supervised) drop to L2 until the accountable person renews the row. Grants at or below L2 keep their level, because a person already approves or performs each action at those levels. The workflow can keep running, but a person has to approve each action the AI used to take on its own, including its reads. That friction is deliberate: it pushes the accountable person to renew the row promptly, revise its grants, or retire the AI’s part in the workflow. If your tooling can’t fully enforce the drop, record the gap in the row’s residual risk cell, together with the manual check that limits it.
- Who renews: The accountable person. They have to base the renewal on the AI’s recent track record for that workflow, the same evidence that would support raising the grant.
- How long: Match the matrix’s default window to a cycle the organization already runs, such as the annual policy review. When a workflow requires a different expiration timeframe, give blast radius the most weight, and adjust for reversibility, autonomy level, and safeguard strength.
The last few sections introduced four mechanisms that revisit the AI’s authority or its actions: the trigger events listed in a row’s Reevaluation cell, the row’s expiration date, the owner’s recurring review of the matrix, and the rollback of a single action. If you conflate one with another, you might record the wrong decision in a row, such as planning to undo a bad action when you should lower the grant instead:
| Mechanism | What it does |
|---|---|
| Trigger event | Reopens a grant when a listed event happens |
| Expiration | Reopens the whole row on its date |
| Recurring review | Reopens any row the owner questions |
| Rollback | Undoes one action, never a grant |
Adopt the Security Autonomy Matrix in five stages.
To put the matrix into practice, work through the following five stages:
- Record the current grants. Pick the two or three workflows where the AI already performs actions whose mistakes would be costly or hard to reverse, or where you’ve already considered granting it that authority. Describe in the five decision columns how the workflow runs today, not how you intend it to run.
- Decide the first renewal. When the first grant comes up for renewal, weigh the AI’s track record and decide whether to keep the grant. This will be the first decision you make through the matrix.
- Award the first promotion. When a grant’s documented track record supports a higher level, promote it, such as a clean quarter at L2 (Supervised) as grounds for L3 (Conditional) within set limits.
- Make the first demotion. When a trigger event is grounds for less autonomy, demote the grant and note the reason in the row.
- Add rows over time. Record a new row for each new workflow where you grant the AI authority whose mistakes would be costly or hard to reverse.
After that, renewals, promotions, and demotions repeat as evidence arrives, in no set order.
Enforce what you recorded in each row.
Configure your tooling to enforce the decisions in each row of your Security Autonomy Matrix to the extent possible. Turn the row’s Autonomy levels into the agent’s permissions and turn its Gate into the control a person uses to approve, override, or roll back the action. For example, to enforce Delete at L2 (Supervised) in a phishing cleanup workflow, revoke the agent’s permission to permanently delete messages, and configure the email product to queue each deletion request until a person approves it.
Few of the products your agents connect to can approve one class of action while letting another run on its own. Evaluate your tech stack for that ability. For example, can your email product hold each deletion for a person’s approval and still let the AI read mailboxes on its own? Where it’s missing, record in the residual risk cell the harm that remains possible and the manual check that limits it. If neither the tooling nor a manual check can enforce the grant as recorded, lower it to a level you can enforce.
Match enforcement with visibility. Ensure your team can distinguish AI actions from human actions, for example, by giving agents their own identities. Enter each change the AI makes in the change record your organization already keeps, such as a ticketing system or a code repository’s history. Route logs that capture the AI’s activity to the systems your team already uses for investigations, and alert on actions outside the row’s recorded limits. Record in each entry what the AI read or changed, when, with what result, and what a person approved or blocked. Auditing an L4 (Independent) grant after the fact requires those logs. Use the same logs to spot when one of the row’s trigger events occurs and reopen the autonomy decision when it does.
The same agent often acts in several workflows, and each row may grant it different autonomy. One row may let the agent delete records on its own, for example, while another requires a person to approve each deletion. In such cases, give the agent a separate identity for each workflow, holding only the permissions that row grants. Enforce each row’s approval requirements in the tooling that runs its workflow, and don’t let the agent choose which identity it uses. A single identity that combines every row’s permissions would let the most permissive row govern all of the agent’s workflows. When you cannot enforce different permissions and approvals per workflow, run the agent at the most restrictive level the rows record for each class. Then lower the recorded grants to match, so each row keeps saying what the AI may do.
Delegation cannot expand authority. When one agent invokes another, it may not use that agent to do anything it could not do itself. An agent allowed to draft but not send gains no send authority by passing its draft to an agent that can send. Scoped identities alone do not prevent that reach-through, so the deployment has to enforce the boundary.
Five metrics show whether the matrix is working.
Track these five metrics over time to see whether the authority you recorded matches what happens in practice:
- Overdue renewals: An expired row that nobody reevaluated means the renewal cycle broke down. Either the workflow has been running under the L2 (Supervised) fallback nobody meant to be permanent, or nobody enforced the drop and the AI kept authority nobody reaffirmed.
- Time from trigger to enforced change: When a trigger event occurs, track two lags: from the event to the reopened decision, and, when the level changes, from the decision to the reconfigured tooling. A lag of days may be tolerable, depending on the grant’s blast radius, but a quarter means nobody enforced the change.
- Renewals without evidence: When the accountable person renews a grant without recording the AI’s track record, you can’t tell whether anyone weighed the evidence before the AI kept its authority. A run of these means the expiration discipline has failed.
- Drift between the recorded grant and the enforced permission: During the owner’s recurring review, check a sample of rows against the tooling settings or manual checks that enforce them, and track how long mismatches persist.
- Incidents traced to a granted autonomy: When you trace an incident to an action the AI took under a recorded grant, assess it against the threshold you set in the row’s Reevaluation trigger. When the trigger fires and you reopen the row, ask whether the residual risk cell was wrong, the safeguard failed, or the harm you accepted materialized, and update the cell that matches your answer.
Give the matrix itself a named owner (e.g., the CISO) and record the events that would reopen every row at once, such as a model change that affects every agent or a regulation that changes what you may automate. Review the matrix on a recurring cadence and reopen any row whose trigger conditions occur. An organization that wants additional oversight can open the matrix to independent reviewers, such as internal audit; its rows record the grants a reviewer would test.
What the matrix is based on, and what is new.
I based the matrix on ideas with long track records and added the parts I haven’t seen elsewhere, such as the five action classes and the five-column decision record. The table below outlines where each part comes from. If you know prior art I missed, please let me know:
| Element | Status |
|---|---|
| Autonomy levels | Adapted from SAE J3016. Mohsin and colleagues applied the same inspiration to the SOC in 2025, Gartner recommended level-based agent governance in May 2026, and CSA’s Jim Reavis proposed six SAE-inspired levels for agentic AI in January 2026. |
| Levels set per function, not per system | Raja Parasuraman, et al., 2000 |
| Minimal agent permissions | OWASP least agency and excessive agency guidance. SANS’s Critical AI Security Guidelines v1.1: “clearly delineated permissions” for agents |
| Human oversight of critical agent actions | SANS’s Critical AI Security Guidelines v1.1: “avoid exposing critical operations without human oversight” |
| One-way and two-way doors | Jeff Bezos, 2015 shareholder letter |
| Blast radius and reversibility as the gate measures | Established operations concepts. Bala Priya C weighs the same pair when deciding how much autonomy a DevOps agent gets. |
| Earned, revocable autonomy | Graded responsibility in medical residency. Stated for agents on DevOps.com. Josh Woodruff’s ATF maturity model describes per-agent promotion and demotion. |
| Expiring grants | Expiring exceptions are established practice, documented by GAO in 1999. Applying a default expiration to AI autonomy grants inside this decision record is my adaptation. |
| Read/write split in agent scoping | CSA’s enhancement of the AWS scoping matrix |
| Pre-approved machine-speed actions | Rob Fuller’s Standing Authority Matrix pre-approves machine-speed actions that are “small and reversible by design.” Rob and I arrived at the same approach independently. |
| Accountable person and residual risk per workflow | Established risk-management practice: named risk owners and recorded residual risk. The matrix’s contribution is recording them per workflow row. |
| Five action classes, including Send, Spend, and Delete | New in this framework. Production permission schemes already grant Send separately, and the matrix records that grant as a leadership decision. |
| Five-column decision record as a leadership operating model | New in this framework |
Thank you to the reviewers.
Thank you to the people who provided feedback on this document so far. The list includes:
- Shawn Chakravarty, SANS Institute
- Viswanath S Chirravuri, Thales Group
- Lara Dawson, SANS Institute
- Kevin Garvey, World Wide Technology
- Frank Kim, SANS Institute
- Ryan Nicholson, Blue Mountain Cyber, LLC
- Jonathan Risto, Zenzizensec
- Joshua Scott, AKA Security
