Lenny Zeltser

The Security Autonomy Matrix: Deciding AI Authority

Mon, 24 Aug 2026 00:00:00 GMT

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 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.

Four more rules cover drafting, combined actions, code, and chains of actions:

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.
Chained actions: When the AI plans a chain of actions, decide the gate before the AI takes the first step. Look at every action in the chain, up to where the AI next stops for approval. Find the action class with the lowest autonomy level among them, and gate the whole chain at that level. Each step keeps its own class. Weigh blast radius and reversibility for the whole chain too. A person needs longer to undo fifty steps than to undo one. Suppose you let the AI isolate up to five workstations per incident on its own. During an incident, the AI plans to isolate six. That plan exceeds the grant, so the AI needs a person's approval before it isolates any of them. If the AI finds the sixth machine only after isolating five, it has to ask then, as it would for any exception. OWASP's AI Security Verification Standard states a related requirement for the software that runs agents: approval gates for multi-step or multi-agent chains "enforce the highest-impact reversibility classification present anywhere in the chain."

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. The rule for chained actions applies across agents too. When the steps of a chain belong to different agents, gate the chain at the lowest level you granted for any step, whichever agent performs it.

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
Reversibility classes and chain gates	OWASP's AISVS 1.0 requires a trusted reversibility classification for each high-impact action, with read-only, reversible, externally reversible, and irreversible as its examples. It also requires approval for a chain at the highest-impact classification anywhere in it. The matrix records reversibility as leadership grants, one per action class. The chained-actions rule is the matrix's counterpart to the chain-level gate.
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

Five Questions to Answer Before Buying an AI Security Product

Mon, 03 Aug 2026 00:00:00 GMT

In the young security-for-AI market, what a product protects and how it ships can differ from what its label promises. With five questions drawn from the AI Defense Matrix Catalog work, you'll know what you're buying, whether that's a capability you already own or an early startup worth a closer look.

In the fast-changing AI security market, a product described one way often turns out to be something else after a closer look. Sounil Yu and I see this while maintaining the AI Defense Matrix Catalog. Per its methodology, we list only generally available or public-preview products that defend AI systems, using AI tooling to check vendor claims against public sources. While deciding what qualifies and what only resembles security-for-AI, I noticed five patterns you can turn into questions to answer before you buy.

Check which asset the product protects.

A common pattern is a product that uses AI to protect traditional assets, marketed as if it protects AI. A detection platform with an LLM-based triage assistant secures the network, and its marketing might say "AI security." The test is to name the protected asset. If the answer is ordinary endpoints, code, or cloud workloads, the product belongs in a traditional category regardless of how much AI powers it. When the same capability targets the AI-specific version of the asset, such as AI-generated code or AI workload platforms, it counts as AI security. Apply the same test to general-purpose governance platforms, which manage risk workflows across the business rather than defend AI assets.

Determine whether you're buying a product or a feature.

Some security-for-AI capabilities are part of a larger platform, such as a single toggle that routes model output through a third-party safety filter, or a bundled setting with no documentation surface of its own. Confirm whether the product you're considering can deliver value on its own or whether deploying it requires committing to the broader platform. A feature can still be the right control for your environment, but in that case, evaluate it as part of the platform it belongs to rather than as a standalone product.

Separate shipping products from roadmaps.

The AI security market is full of future-tense products, including capabilities described in press releases, high-level launch announcements, and websites that offer a sales call instead of product details. When a pitch presents a roadmap item as a present-tense capability, ask for specifics: delivery timeline, documented capabilities, reference customers you can talk to. If you buy a product with yet-to-be-delivered features, know what you're committing to and what recourse you'll have if they never ship.

Find out whether you already own the capability.

A newly branded AI security offering may package capabilities your organization already licenses. Established vendors combine acquired products with their existing platforms, and they may also add AI-specific features to products you already own. Another team in your organization may already operate the control you're considering. Before you add a product to your shortlist, map what you already own to the AI Defense Matrix and ask your current vendors for details about their security-for-AI additions.

Buying from a startup takes more diligence and offers more influence.

Sometimes a young but promising product offers little public evidence. The website has no product pages yet, third-party coverage is the only source for the claims, or the vendor keeps the documentation behind a sales gate. In a market moving this fast, a startup can ship an innovative product before it has third-party validation, broad coverage, or comprehensive documentation. If you're comfortable buying from an early startup, expect to work harder to understand and validate the product. Ask the vendor for documentation, and run a proof of concept before you rely on the capability. The advantage is that you can get involved early, potentially as a design partner shaping the product's roadmap and priorities.

The five patterns double as a buyer's checklist.

When you evaluate a security-for-AI product, look for answers to five questions:

What AI asset does the product protect, specifically? The AI Defense Matrix offers the terminology you can use.
Can the product deliver value on its own, or does it require committing to a broader platform?
Which pitched capabilities are fully available now, and which are still on the roadmap?
Does your organization already own and operate this capability, perhaps as a feature of another team's product?
What evidence supports each capability claim, and how much validation will you need to do yourself?

Answer the five questions early, and you'll know what the offering protects, whether you already own it, how it's packaged, whether it works today, and how much validation it needs from you. The shape of AI security shows what the qualifying products reveal about this young market, and the field guide helps you evaluate the products you shortlist.

A Field Guide to the AI Security Market

Thu, 30 Jul 2026 00:00:00 GMT

The market for products that secure AI is crowded and hard to read, with overlapping categories and products that each do many jobs. With the AI Defense Matrix, you can ask the right questions, tell what a product was built for, and staff the gaps no product fills yet.

Sounil Yu compares the general security product marketplace to a disorganized grocery store, where products pile up without aisles to organize them. The AI security market is such a store, too. Product categories overlap, vendors name products after ambitions rather than capabilities, and the same demo can support multiple pitches. Buyers can't find what they need, and sellers struggle to explain what their products do.

Sounil and I built the AI Defense Matrix Catalog to make sense of the AI security marketplace. The catalog maps each product to the cells of the AI Defense Matrix, which crosses eight AI asset classes with six NIST CSF functions, so each cell pairs one asset class with one security function. It illustrates where products cluster and where coverage is light. I explored what that distribution reveals about the market's structure in the shape of AI security article. This guide is the buyer's companion, with cluster-by-cluster questions to ask vendors when evaluating a product that secures AI.

Four clusters fill the crowded cells.

There are four product clusters in the catalog's crowded cells, each with its own questions to ask before you buy.

AI runtime guardrails: The products in the catalog's largest cluster protect and monitor runtime AI data, meaning prompts, inference traffic, RAG content, and agent memory. These products filter what enters and leaves models, redact sensitive data, and flag policy violations. The pattern is familiar from web application firewalls and DLP, and most bundle protection and detection in one product. The catalog lists more than a hundred products that cover runtime AI data. Frank Wang writes in Frankly Speaking that "as an industry, we haven't even fully figured out what guardrails we should be enforcing, or what level of autonomy we should grant an internal agent." Ask where the product inspects traffic, which prompts and other data leave your boundary, and what happens to your AI application when the vendor's service goes down.

Agent identity and access: Products in the second major cluster treat AI agents as non-human principals that need credentials, permission scopes, and lifecycle management. Identity incumbents such as SailPoint and Saviynt extended their platforms here, and dozens of startups joined them. Agents are a new kind of principal in the familiar discipline of identity management. Ask how the product handles delegation chains, where an agent acts for a human or through another agent, and how quickly you can revoke a misbehaving agent's credentials, including what happens to its in-flight delegations.

Model scanning and posture: Products in the third cluster inspect AI models and pipelines, scanning model files for tampering, testing for adversarial weaknesses, and inventorying which models run where. Think of it as vulnerability management and red teaming aimed at models. Ask whether your team can turn the findings into fixes, and which model formats and pipelines the scanner supports.

Orchestration and MCP security: Products in the fourth cluster secure AI orchestration tools, including MCP servers, plugins, and the scaffolding around agents. Ask what the product can see across your agents and plugins, what it can restrict, and how it detects an agent acting outside its scope.

A few products cover the near-empty cells.

Fewer than a dozen products cover any Respond or Recover capability, and those few are an early sketch of AI incident response tooling, including agent containment through identity suspension, machine unlearning positioned as model recovery (Hirundo), and rollback of agent actions (Rubrik Agent Cloud). These functions depend on people more than on technology, as I explored in the shape of AI security article. Treat response and recovery for AI incidents as work for your people, your playbooks, and the recovery tooling you already own.

Most products cover more cells than they were built for.

The AI Defense Matrix Catalog records how central each coverage claim is to the product's purpose. About a third of the coverage claims in the catalog are "secondary" or "adjacent," meaning areas the product supports rather than its central purpose. Most products in the catalog cover three or more cells. When a vendor pitches broad coverage, ask what the product was built to do and which capabilities the vendor added along the way, then check the answers against the product's catalog entry.

Add vendor viability to your evaluation checklist as well. Acquirers have already absorbed more than one in ten of the products in the catalog, and the market is only a few years old. Expect the crowded cells to keep consolidating. Ask about change-of-control terms, data portability, and the migration path if another vendor absorbs the product.

Decide which cells you need before you evaluate products.

Review the AI Defense Matrix against your AI security requirements to prepare for vendor discussions:

List the matrix cells that matter most for your AI deployments by pairing each AI asset you use with the functions your program needs for it.
Check whether the products you already run cover those cells before you evaluate new ones.
For crowded cells, select a few vendors and evaluate them in your own environment. Products within a cluster differ more in operations than in demos.
Check each product's AI Defense Matrix mappings in the catalog to better steer those discussions.
For cells you need to address that are empty in the catalog, devise a process, owned by a named person, instead of waiting for a product.

Match products to the cells your AI deployments need, and staff the rest with people and processes.

Cyber Company Profiles: Independent Analysis of Security Vendors

Tue, 28 Jul 2026 00:00:00 GMT

Judging a security vendor from its own materials tells you little about how it compares to the rest. Cyber Company Profiles scores hundreds of cybersecurity companies from public sources.

Cyber Company Profiles is a free site that analyzes the market positions and product strategies of cybersecurity companies. My AI tooling produces each profile from public sources, sifts through the data to answer a fixed set of questions, and scores the answers consistently. I created this tool to understand the cybersecurity product landscape better.

The questions the site answers are the ones I kept asking in my own work. As a buyer of security products, I wanted to see where the vendor was taking its portfolio and whether it would keep innovating after I committed. And I wanted to know whether a startup would still be around in two or five years. As a product leader, I wanted to understand the competitive dynamics and market pressures my roadmap had to withstand.

Generic AI assistants will answer those questions inconsistently. The results change with each run, depending on how you direct the AI and what it finds that day. One investigation is not necessarily comprehensive or even correct, and when you rerun it, you get yet another answer. The variability also means you can't compare findings across companies.

Start with a company that's on your mind.

Cyber Company Profiles covers hundreds of cybersecurity companies, and the entire site is free to use. Read any company's profile to see its summary, its scores with the rationale behind each one, and a deep dive into the strategy. You can also use your AI agent to fetch the data through an API.

If you're a buyer preparing to talk to a vendor, read that vendor's profile before the conversation. If you're a builder, search for your own company, or explore another vendor in your market. Compare the analysis against your own view, and when you disagree, follow the sources each profile cites and decide for yourself.

Standard questions make AI research comparable.

I built Cyber Company Profiles on three published frameworks, which supply the questions, the scoring scales, and the structure of each profile. For every company, AI gathers the public record, answers those questions, and scores the answers against those scales. Here are the frameworks:

The Market Readiness Scorecard measures how well a company can compete in its security market. Its dimensions, such as market timing and team credibility, are based on my RSAC Innovation Sandbox analysis.
The Security Product Creation Framework organizes the strategy deep dive, the narrative part of a profile. I laid it out in my guide to creating security products.
My adaptation of Ben Vierck's Defensibility Rubric measures how well a company holds its position as AI lowers the cost of building software. I've applied his rubric to security vendors before.

Cyber Company Profiles puts every company through the same questions and the same scales, making scores comparable across companies. A profile rates market readiness as Emerging, Established, or Advanced, based on the company's score relative to those analyzed so far. Established is the most common of the three, so the rating tells you at a glance whether a company scores above, within, or below the typical range.

Every claim in a profile links to the public source behind it, so you can verify anything you plan to act on.

The analysis is independent and limited to public sources.

I run Cyber Company Profiles independently of the companies it covers. No company pays for coverage or sees its profile before publication. If a profile gets something wrong, anyone can report the error through the site.

AI builds each profile solely from public signals, so the profiles have the limitations of any open-source intelligence analysis. AI has no access to internal metrics, customer references, or roadmaps that might change the conclusions. A company doing good work quietly will also look thinner than one that publishes often. And each profile is a snapshot that a company can outgrow. AI can also misread a source or miss the context a domain expert would catch.

Even so, seeing how a company looks from the outside, based only on its public record, is useful. Treat each profile as one informed opinion to check against your own diligence.

What 239 Products Reveal About the Shape of AI Security

Sun, 26 Jul 2026 00:00:00 GMT

The security-for-AI market is young and lopsided. Incumbents quickly extended their products into the AI versions of assets they already secured, while the more distinct AI assets drew startups and incumbents alike into markets that stay active and contested.

The AI Defense Matrix Catalog tracks products that defend AI systems, mapping each one to the AI Defense Matrix. Sounil Yu and I maintain the catalog with the help of AI and community contributions. The goal is to understand how each product fits into the security-for-AI ecosystem.

The matrix crosses eight AI asset classes with six NIST CSF functions, so every cell pairs an asset with a security activity. As of this writing, the catalog lists 239 products. Their distribution across the matrix is uneven: Some cells are dense with products, while others have no coverage. What does that tell us about the AI security marketplace and the role of people, process, and technology?

Most products cluster in a few asset classes and functions.

Each mapping of a product to a matrix cell is one coverage claim, and most products cover several cells. The majority of products in the AI Defense Matrix Catalog protect the following AI asset classes:

Runtime AI Data (244 coverage claims): User prompts, inference inputs, RAG content, vector DB content, persistent agent memory, and interaction history
AI Orchestration Tools (212 coverage claims): Agentic orchestration tools, plus their plugins, skills, hooks, system prompts, scaffolding, harnesses, configuration settings, and MCP clients on user devices
AI Agent Identities (142 coverage claims): AI agents as non-human principals, plus credentials, keys, permission scopes, service accounts, and delegation chains across agents and tools
AI Model (116 coverage claims): The AI model itself, including its weights, integrity, provenance, and selection

The following activities that NIST CSF expects of a security program are best represented in the catalog:

Protect (312 coverage claims): "Safeguards to manage the organization's cybersecurity risks are used"
Detect (302 coverage claims): "Possible cybersecurity attacks and compromises are found and analyzed"
Identify (202 coverage claims): "The organization's current cybersecurity risks are understood"

The totals above therefore exceed the catalog's 239-product count. Only 16 products in the catalog defend a single cell.

Almost half the products cover the single most crowded cell, which is protecting runtime AI data. More than a quarter of the grid's 48 asset-and-function cells are empty.

Products cluster where technology can do the work.

When Sounil applied NIST CSF functions to the Cyber Defense Matrix, he explained the coverage imbalance. He noted that "technology plays a much greater role in Identify and Protect"; dependency on technology diminishes across Detect, Respond, and Recover while dependency on people grows, and dependency on process changes little across them. That continuum applies to any asset that those functions organize, including AI-specific ones. The catalog shows a more pronounced version of that gradient: Coverage stays dense through Detect, where technology still does much of the work, and drops steeply in the functions that depend on people.

The AI Defense Matrix includes the Govern function, which the Cyber Defense Matrix doesn't have. It's one of the least-covered functions in the catalog because:

Govern represents primarily human decisions, judgment, and oversight.
The catalog captures security for AI, so it leaves out general governance tools such as GRC platforms.
AI governance is also young, and we might see more products that cover AI governance as this function evolves.

The people end of the continuum is nearly bare. Nine products in the catalog cover any Respond capability for AI assets, and two cover Recover. We deliberately searched for these and mostly found announcements, future-tense capabilities, and general-purpose recovery tools marketed with an AI label.

Established vendors covered the familiar assets, and new markets formed around the rest.

Some AI asset categories are variations of traditional assets that established vendors have already secured in the pre-AI era. Those vendors extended their coverage to the AI versions, leaving less room for startups in these rows:

AI-generated code is still code, so application security firms such as Checkmarx, Snyk, and Semgrep cover it.
Training data is still data, so data security firms such as BigID and Cyera cover it.
AI workload platforms are still infrastructure, so cloud security firms such as Wiz and Tenable cover them.

In contrast, runtime AI data, agent orchestration, the model, and agent identities are more distinct, new types of AI assets that are distant from traditional asset categories. As a result, a new market of vendors formed around each of them, mixing startups and incumbents, with AI-native firms such as Lakera and Astrix Security alongside Palo Alto Networks and Okta. These markets are active, still unsettled.

Across the whole market, established security vendors are absorbing AI security by extending their own products and acquiring startups. In a funding analysis spanning three years, Mike Privette found that all AI security funding, from products securing AI to products using it for security, accounted for 9% of cybersecurity funding deals and 3% of the dollars invested. He interprets these dynamics as absorption, similar to what occurred in cloud security. More than one in ten of the AI Defense Matrix Catalog entries have already been acquired, in a market only a few years old.

The contested cells are where the market is still forming.

Established vendors expand their products and startups dream up new solutions, looking for ways to help organizations defend AI-specific assets. The AI Defense Matrix Catalog shows products crowding the cells where technology plays a key role, and thinning out elsewhere. Though the market for such products is still young, its contested areas are where innovation and acquisitions will continue to occur.

Benchmark Your AI Security Decisions: A Five-Minute Survey

Mon, 20 Jul 2026 00:00:00 GMT

Answer ten questions about how your organization secures AI, and you get a peer benchmark in return. Sounil Yu and I will publish findings on which AI assets peers protect, who decides, and where controls come from.

Security leaders are making AI security decisions with almost no data about how their peers handle the same choices. Existing surveys measure AI adoption, incidents, and governance policies, but not which assets organizations protect or who makes the decisions.

Sounil Yu and I built a short survey to start closing that gap. We'd like your help turning it into a benchmark the whole community can use. If securing AI is part of your job, whatever your title, the survey is for you.

The survey asks how your organization secures AI in practice. Its ten questions take about five minutes and cover:

Which AI-related assets your organization considers part of its attack surface.
Which of those assets you protect with at least one dedicated control.
Who decides how your organization secures AI.
Whether your AI security controls come from existing tools, specialized vendors, AI providers, or tools you build in-house.

You'll get a peer benchmark in return. Sounil and I will publish the aggregate findings, so you can compare your approach against others facing the same decisions.

Your answers are anonymous. If you want to see the findings early, leave your email at the end; we'll use it only for that mailing.

Take the survey, and pass it along to a peer who owns AI security.

We'll keep the survey open for a few weeks. The more security leaders respond, the more useful the benchmark becomes for all of us.

A Report Template for Malware Analysis

Thu, 18 Jun 2026 00:00:00 GMT

A malware report is only as useful as readers' ability to find in it what they need. This customizable template organizes the findings into a coherent structure, so a responder, a manager, or a fellow researcher can benefit from the analysis.

Malware analysis produces many insights about a sample, its capabilities, and detection opportunities. But communicating those details so others can act on them isn't easy. The malware analysis report template helps with that. It gives analysts a structured way to present what they found, from defender-actionable findings to the supporting analysis behind them.

Download the Template

Download the template and make it your own. It's available as Markdown and Word files.

You can also use my MCP server with your AI agent to generate or improve malware analysis reports using this template and my guidance. It's designed to offer insights without receiving your sensitive data. To use it, add https://website-mcp.zeltser.com/mcp to your AI agent's config.

If you'd rather build your own tooling around my guidance, you can also download my insights as a YAML file, which your AI tool can use in a way that fits your needs.

How the Report Is Organized

The report template organizes its content so readers can quickly find what they need. For authors, it offers placeholders and guidance to capture, explain, and share their findings. The template works for the analysis of a single file and a chain of related artifacts.

Executive Summary: A paragraph explaining what the sample is, how it gets in, and what it does.
Sample Snapshot: A quick-reference profile covering the malware family and confidence, key capabilities, target platform, the primary artifact, and the infection vector.
Malware Family Identification: A structured record of the family the sample belongs to, the basis for that call (such as a YARA rule, string overlap, or code reuse), and the confidence level.
Component Inventory: One row per file or artifact in the sample set, capturing role, file name, type, and notes, with a short flow description for multi-component samples.
Runtime Requirements: What the sample needs to run, including OS dependencies (DLLs, registry keys, runtime versions) and ecosystem dependencies (permissions, manifest declarations, marketplace identifiers, abused APIs, etc.).
Sources: Where the sample and supporting data came from, such as internal telemetry, OSINT, or partner sharing.
Capabilities: Observed behaviors mapped to the Malware Behavior Catalog, including anti-analysis behaviors.
Indicators of Compromise: Indicators in a structured table covering hashes, IP addresses, domain names, cloud resources, network artifacts, and host artifacts.
Analysis Details: The supporting evidence behind the key findings, with subsections for automated, static properties, behavioral, memory, and code analysis.
What We Don't Know: What the analysis couldn't resolve, couldn't trigger, or couldn't verify.
Infection Vector (Optional): How the sample reached the target, referencing MITRE ATT&CK Initial Access techniques where applicable, with the distribution URL or source path when known.
Detection Engineering (Optional): Detection logic that generalizes beyond the listed indicators, such as a YARA rule keyed to the family. Sigma and other SIEM or EDR rules are optional.
About this Report: The report metadata, including title, authorship, classification, follow-up contact, and a changelog.
Appendix: Analysis Environment: The environment used for the analysis, such as REMnux or FLARE VM, plus the sandbox configuration, etc., so other analysts can reproduce the work.
Appendix: Analysis Scripts (Optional): Links to any config extractors, deobfuscation scripts, or notebooks used, so others can reproduce the findings.

Frameworks Behind the Template

The template incorporates established frameworks where they fit:

The Malware Behavior Catalog is the practitioner-facing taxonomy for what malware does, and the Capabilities section maps the sample's behaviors to it. MAEC is the machine-readable sibling specification.
MITRE ATT&CK names adversary techniques. The Infection Vector section references its Initial Access techniques, and the Capabilities section cites an ATT&CK technique in its Notes column when a behavior has no fitting MBC entry.
David Bianco's Pyramid of Pain is a ranking of indicators by cost to the adversary. Hashes are trivial to change. Behavioral artifacts cost the adversary more.
ICD-203 defines the high, moderate, and low confidence levels the report uses to rate its malware family identification.

Related Cybersecurity Templates

A malware analysis report describes the sample and its artifacts. Other templates help you respond to incidents involving the malware, investigate the threat actor, and understand the exposure:

Incident response report template: Use it when handling the incident that involves the malware sample.
Cyber threat intelligence report template: Use it when shifting from the sample to the actor or campaign behind it.
Vulnerability investigation brief template: Use it when the sample arrived through a malicious dependency, such as a backdoored open-source package, or through an unpatched vulnerability.

Templates for Cybersecurity Executive Briefings

Sun, 14 Jun 2026 00:00:00 GMT

In an effective executive brief, you lead with the bottom line and what a finding means for your organization. Use these four customizable templates to do exactly that across threat intel, vulnerabilities, incidents, and assessments.

We often update decision-makers about threat actor campaigns, celebrity vulnerabilities, security incidents, and the findings of a security assessment. The following templates for executive briefings structure the narrative into a short document that captures the details executives want to see. Customize and use them to enable informed decisions.

Customize and Use the Templates

I prepared the following templates for cybersecurity briefs based on my experience as a CISO and hands-on practitioner. Adjust them to the way your organization prefers to capture and communicate such details.

Brief	What it covers	When to use	Download
Cyber Threat Intelligence	Threat actor or campaign analysis	Use it to distill a full CTI report for leaders, or to synthesize vendor and government reporting on an emerging threat.	Markdown, Word
Vulnerability Investigation	Celebrity vulnerability assessment	Use it when a vendor or government advisory discusses a vulnerability your organization needs to evaluate. Base it on the details available about the issue and your organization's exposure to it.	Markdown, Word
Incident Response	Cybersecurity incident update	Use it during an incident, after containment, or for an incident too small for a full report. Distill from a full IR report, or use the brief as your working document.	Markdown, Word
Cybersecurity Assessment	Findings from a security assessment	Use it to distill a full assessment report for leaders, after a penetration test, vulnerability assessment, or other findings-based engagement.	Markdown, Word

Design Criteria for the Briefs

I designed the templates to incorporate the key elements from the Cybersecurity Writing course that I teach at SANS Institute. All four reflect content I've produced and received as a security professional:

Bottom line first. Each brief opens with a paragraph that immediately captures the key takeaways important to the reader. State what happened, who's behind it or what's vulnerable, and the most important defensive action.

Organizational context. Each brief includes a placeholder for interpreting findings in your organization's context. For vulnerabilities, that means a significance ranking adjusted for exposure, compensating controls, data sensitivity, and asset criticality. For threat intelligence, that means calibrated confidence in your assessment and your exposure to the campaign. For incidents, that means impact in terms your decision-makers care about. For an assessment, that means findings rated by risk to the organization.

Action informed by analysis. Each brief includes a table for capturing and driving action informed by the analysis. The CTI and Vulnerability briefs call it Defensive Actions. The IR brief calls it Response Actions, drawn from the response phases of Identification, Containment, Eradication, and Recovery. The Security Assessment Brief calls it Recommended Actions.

What you don't know. Most of these briefs include a "What We Don't Know" section listing the assessment gaps. Naming the gaps signals discipline and sets expectations for new information. Over time, that practice builds the executive trust that makes future briefs land faster.

Built for skimming. Each brief uses tables for facts and actions, with headings that serve as landmarks. Readers can quickly find the details they need without reading the brief end to end.

Pair the Briefs with Longer Reports

Briefings for decision-makers generally draw on a longer source that captures the details of the analysis. I created the following resources to help you build such baseline materials:

Cyber Threat Intelligence Report Template is the full methodology behind the CTI Brief.
Escaping the Vulnerability Management Hamster Wheel is the context-adjusted significance discipline behind the Vulnerability Investigation Brief.
A Report Template for Cybersecurity and Privacy Incident Response is the full IR methodology behind the Incident Response Brief.
A Report Template for Security Assessments is the full methodology behind the Security Assessment Brief.

Use the briefs in your conversations with decision-makers. Reserve the long-form reports for when you need to back the brief with detail, share findings with technical audiences, and build institutional memory beyond the contents of the brief.

Handling High-Profile Vulnerabilities

Tue, 09 Jun 2026 00:00:00 GMT

When a high-profile vulnerability surfaces, executives and customers want to know whether it affects you. With a one-page brief and a short process, you can capture the key details and reach the answer without scrambling.

As a CISO, I received the same question whenever a vulnerability became famous. Are we affected? A colleague shared the headline, wanting to know whether it affected the business. A customer's security team sent a questionnaire asking whether we'd patched it. A repeatable process for investigating your exposure to a vulnerability lets you address these concerns without scrambling.

First, a useful resource for you. Then, a discussion about what's behind it:

I created a short Vulnerability Investigation Brief you can use to capture and share your analysis of an important vulnerability and your exposure to it. Download the template and make it your own, as Markdown and Word.

Now you have the template. It's designed for high-profile vulnerabilities about which you need to communicate with stakeholders, for instance in "celebrity" vulnerability situations. Let's explore how to get the most out of the template.

A checklist for assessing your exposure.

You should design your vulnerability management program so that routine vulnerabilities are handled routinely and automatically with minimal ad-hoc attention. But some vulnerabilities, including those that arise from third-party dependencies, require special attention.

When a vulnerability of such significance surfaces, go through the following steps to understand your exposure:

Confirm you even run the affected product, version, and configuration. That takes asset visibility, and you often find you don't, which closes the investigation.
Check whether it's realistic for an attacker to reach the flaw. A disabled feature, a blocked port, or a segmented network can remove your exposure or buy you time.
Re-rank the vendor's worst-case severity for your exposure, compensating controls, data sensitivity, and asset criticality.
Convert the call into an action someone owns by a real date, or decide it needs none. An assessment nobody acts on is only an opinion.

These steps apply to a compromised dependency that you need to investigate, such as a backdoored software package. In this case, if you determine that you're affected, you'll shift to incident response mode (I have a template for IR too).

Communicating the vulnerability investigation.

The Vulnerability Investigation Brief is designed to address the questions that your colleagues, especially executives, want answered:

Bottom Line explains what the vulnerability is and how it affects the organization.
Quick Facts summarizes key details about the situation with placeholders to explain the significance of the vulnerability, affected resources, attack vectors, and more.
Are We Affected? offers guidance for answering this critical question.
Defensive Actions captures the work that needs to be done, complete with who will be doing what, why, and when, to move the situation forward.
What We Don't Know lets you capture the gaps, which signals discipline and tells the reader when to expect more.

The template is designed for the internal audience. But the details captured within it are the foundation for an outbound message you might need to draft for your customers and other external parties. Work with the right comms team or person for externally-facing content.

Don't let the hype take over.

Every so often, a vulnerability arrives with its own branding. I first saw the term "celebrity" vulnerabilities in Trustwave's 2015 report, which defined it as vulnerabilities that "receive memorable names, and sometimes logos, from their discoverers." Security expert Troy Hunt later observed that such branding "has a way of drumming up excitement and sensationalism in a way that isn't always commensurate with the actual risk."

The celebrity vulnerability might be minor and you might not even be exposed to it. Yet, the media hype about the issue can draw outsized attention that distracts from more important work, as questions about it ricochet through the company and to its suppliers.

Don't get distracted by the noise. Run the vulnerability through the checklist and template to address any concern calmly, celebrity or not.

Securing API Keys on Your Workstation

Tue, 09 Jun 2026 00:00:00 GMT

Every dev tool you grant API access to, AI assistants included, can read the keys within its reach. No setup removes that risk entirely, so the goal is fewer secrets exposed and less damage when one leaks.

Developer workstations accumulate API keys and other secrets that malware can read from .env files, shell history, and saved CLI credentials. An infostealer only has to steal the key, and using it skips the second authentication factor a person would need. AI agents increase the risk, since they generally require broad access to be useful.

For example, attackers behind the s1ngularity attack compromised nx, a popular JavaScript build tool, and pulled API keys and SSH keys from over a thousand developer machines. The attackers also weaponized developers' AI coding agents, prompting installed CLIs to comb the filesystem for secrets.

Several free open-source tools can help reduce the number of secrets you leave exposed and limit the damage when one of them leaks.

Start by seeing what's already exposed.

Before you change anything, scan your workstation to learn where secrets already live. A good starting point is bagel, which reports secrets and insecure settings across your system, including AI tool credential files, cloud keys, and unsafe Git or SSH configurations.

For secrets already committed to Git, a verifying scanner such as TruffleHog can not only locate the access keys but also test them against the provider to determine whether they still work.

Your first scan will probably find more secrets than you remember creating. Re-run it after each cleanup step to confirm the count drops.

Aim for four reachable wins.

Your tools need access to the API keys and tokens to do their job, so reduce both the chances they're abused and the damage when one leaks. To do that:

Keep secrets out of plaintext files.
Stop them from spreading into Git and logs.
Require your approval before a sensitive key gets used.
Minimize the damage if a key leaks.

Your exposure and convenience depend on where you put your secrets, so let's start there.

Weigh exposure against convenience.

You can keep a secret in several places, from a plaintext file to a vault that prompts you each time. More protection usually means less convenience, so the right store depends on the key's sensitivity, what you're defending against, and how much inconvenience you're willing to tolerate.

A secret's exposure in a store is based on two factors:

Whether software running as you can read it without your approval, and
How many other secrets an attacker gets by compromising that store.

The table below rates the store options on both, so you can pick the approach that works for you.

Approach	Silent read by malware running as you?	Blast radius of one compromise	Automation / headless	Key tradeoff
Plaintext File (e.g., .env)	Yes	The keys in that file	Works everywhere	Most leaks start here
OS Keychain	Yes, while unlocked	That store's items	Good, auto-unlocked	Once unlocked, code running as you can read it, with a per-item prompt on macOS
Password Vault (e.g., 1Password)	No, each use needs approval	The whole authorized account	Poor, needs a person to approve	One approval, or an open session, exposes the account
Scoped Password Vault	No	Only that one vault	Poor, still interactive	Needs an extra limited identity to set up
Service Account	The token sits at rest	Only its granted vaults	Good, non-interactive	The token unlocks everything in its scope

The OS keychain is convenient but stays unlocked.

If you're not sure where to start, the OS keychain is a good default, since infostealers often focus on plaintext files. Every major desktop platform includes one:

macOS: The macOS Keychain, driven by the security command.
Windows: Credential Manager, via cmdkey.
Linux: The Secret Service, via secret-tool.

The keychain is unlocked the entire time you're logged in, which is both convenient and risky. The convenience is that your tools read a key without prompting you, even ones running in the background or headless. Your system usually unlocks it at login and holds it open for the session, so code running as you can read the keys it stores. On Windows and Linux, that code reads the store without prompting. macOS adds a per-item prompt when an app tries to access something it didn't store, though there are ways around it. A file scraper still finds nothing, but code that reads the keychain directly gets the key.

Getting the secret to a tool is its own task.

How you deliver a secret depends on how the tool is started. If you start the tool yourself, you can inject the secret as you launch it. A tool that another program spawns or runs headless needs an auto-unlocked store or a lookup at the moment of use.

You can get the secret to a tool in three ways:

You look it up at the moment of use, for example, using security find-generic-password or 1Password's op read.
You inject it into the tool's environment when you launch the tool.
The tool reads it from its own config file, where you've replaced the secret with an environment variable reference.

You can use these methods with any store you choose.

A password vault adds a per-use checkpoint.

For the few sensitive keys you want to approve each time, use a vault such as 1Password instead of the OS keychain. Unlike the keychain, 1Password asks for your biometric approval at the moment a tool needs the key, and caches it only for a short session. You replace the literal key with a 1Password secret reference in a config or env file, and 1Password's CLI resolves it to the value when a tool needs it.

The downside of using 1Password is that once you give the tool access, it can read all data stored in your 1Password account, not just the secret you have in mind. As a result, if you or your AI tool is tricked into requesting access, you might inadvertently give the requesting software access to a lot of sensitive data.

To lower your exposure, consider creating a 1Password vault just for the secrets you use for your dev work. Then, create a limited 1Password identity with access restricted to that one vault. Cleanly doing that requires a service account that's available only to 1Password business customers. You can mimic this approach using a guest account on a personal plan.

On a personal plan, the guest route needs one more step. You need to turn off the app's biometric CLI integration and sign in as the guest from the terminal. Signing in manually requires a password for the guest account and doesn't work with 1Password biometric authentication.

For a hybrid approach, keep everyday and automated secrets in the OS keychain. Reserve a scoped vault for the few keys you want to explicitly approve. This gives you low-friction storage for your routine keys and a per-use checkpoint for the few that matter most.

Stop secrets from sprawling into Git, history, and transcripts.

By the time you store a secret well, your tools have already written copies of it into Git, your shell history, and AI transcripts. Clean them up, then keep them clean:

Git: Once you commit and push a secret to a repo, deleting the line or rewriting history only reduces the trace, so treat it as burned and rotate it. To catch the next secret before you commit it, run a scanner such as betterleaks (the successor to gitleaks) as a pre-commit hook, which blocks any commit that contains a secret.
Shell history: Your shell records the commands you type, including any key you paste on a command line. Keep the secret off the command line and put a reference there instead, so your shell resolves the secret only when the command runs. When a tool wants the key as an argument, read it inline, as in mytool --token "$(op read 'op://...')". When a script reads the key from the environment, export a reference the same way, as in export GITHUB_TOKEN="$(op read 'op://...')". When you must type the secret directly, fall back to history hygiene, such as Zsh's setopt HIST_IGNORE_SPACE, which drops any command you prefix with a space. To clean keys already in your history, bagel scrub redacts them in place.
AI session transcripts: AI tools log your sessions, and a secret you paste into a prompt ends up in those logs. Scrub them with a tool built for it, such as bagel scrub, which replaces secrets with redaction markers and leaves the conversation readable.

Even after you store secrets well and scrub old copies, your AI tool can still read whatever's on disk, the same access the s1ngularity attack turned against developers. Blocking the tool from credential paths is a separate defense from storing them properly. Even an agent hijacked by a prompt or a bad package then finds nothing to read there. The Trail of Bits Claude Code config, which the Personal AI Stack points to, blocks reads of common credential paths.

SSH keys and config-file keys need their own handling.

Keeping a secret in a store and handing it to a tool on demand doesn't work in all scenarios. For an SSH private key or a key that a tool reads from its own config file, such as npm's .npmrc, handle each on its own terms:

SSH keys: Move your private keys into an SSH agent such as the 1Password SSH agent. It authenticates your SSH connections, including Git over SSH, so the private key never leaves the vault. You approve each attempt to use a key, which grants access only to that key, not the rest of your 1Password account. Alternatively, on a Mac, Secretive stores SSH keys in the Secure Enclave, where even software running as you can't export them; it prompts for strong authentication each time a key is accessed.
Config-file keys: A package manager or CLI may read its key from a file it owns. For example, npm has ${VARIABLE_NAME} support for .npmrc files. When a tool can't reference a variable, lock that file down with strict permissions, keep it out of Git, and rely on scoping and rotation to limit what a stolen copy is worth.

Where to start.

You don't have to do all of this at once. Here's one way to order your efforts:

Scan your workstation to see what's exposed.
Rotate anything that ended up in Git, a shared drive, or a cloud location, since you have to assume it leaked.
Put everyday and automated keys in your OS keychain, and move your most sensitive interactive keys into a scoped vault.
Keep secrets off the command line, and add a pre-commit scanner so they can't slip into Git.
Scrub the secrets already in your shell history and AI transcripts.
Move SSH keys into an agent.
Scan again to confirm the count dropped.

Keep fewer secrets within reach, and match each one to its sensitivity and how it's used, so a single leak stays small.