One matrix, five sets of eyes

THOUGHT-LEADERSHIP

One matrix, five sets of eyes

Securing an AI agent is not one job, and pretending it is one is one of the quieter reasons these programs fail. The person writing the code, the person writing the alerts, the person trying to break it, the person answerable to the regulator, and the person on call when it goes wrong are doing genuinely different work. Hand all five the same control written in one voice, and at least four of them have to translate it before they can act. Many control matrices are written primarily for implementers. I did not want to do that.

So every control in this matrix reads through five sets of eyes, and you can switch the view to whichever one is yours. Here is who they are, in plain terms:

  • Engineering builds and ships the agent. They need the pattern and the steps.
  • Detection engineering writes the alerts that fire when something is wrong. They need to know what "wrong" looks like in the data.
  • Red team attacks the agent on purpose, to find the holes before someone else does. They need the bypass.
  • GRC (governance, risk, and compliance) answers for whether the thing meets policy and law. They need the evidence.
  • SecOps, the defenders, respond when an incident is actually happening. They need the fastest lever.

The point is not five summaries of the same sentence. It is that a single control genuinely is five different things depending on where you sit. The clearest way to show that is to take one control and walk it around the table.

One control, five readings

Take the immutable audit trail, the control that says: write down every tool call, change, and decision in a record that cannot be quietly altered. Here is how each seat reads it.

  • Engineering hears a build task: ship the agent's events, the tool arguments, the state changes, the decisions, to an append-only, hash-chained store that lives outside the agent's reach. (Append-only means you can add but never edit; hash-chained means each entry is cryptographically linked to the last, so any later tampering breaks the chain.)
  • Detection hears a data source, and a tripwire: those same logs are the primary feed for spotting trouble, so the first alert to write is the one that fires when the log stream goes quiet or the chain fails its integrity check. If you lose the record, you have lost your eyes.
  • Red team hears a target: can I make the agent rewrite or delete its own history? If the audit trail can be edited from inside, every other control built on top of it is standing on sand.
  • GRC hears evidence: an append-only log with a defined retention period maps directly onto the EU AI Act's Article 12 record-keeping duty. This is the artifact you hand an auditor.
  • SecOps hears reconstruction: when the incident is over, a tamper-evident timeline whose integrity you can independently check is what lets you say exactly what happened, in what order, and stand behind it.

Same control. Five jobs. None of them wrong, none of them complete on its own. The engineer's perfect implementation is worthless if GRC cannot produce it for an audit, and the most rigorous audit is worthless if the red teamer can quietly delete the entries.

It is the same story everywhere

This is not a quirk of one control. Take the human hard-stop on irreversible actions. Engineering builds a deterministic approval gate enforced outside the agent. Detection alerts if an irreversible action ever completes without a matching approval. Red team tries to get the agent to approve itself or talk its way past the gate. GRC treats the approval record as direct proof a human authorized the action. SecOps sees the gate as the last brake before something unrecoverable lands. Five seats, five reasons the same control matters.

Or agent identity. The engineer issues each agent its own verifiable credential. Detection alerts when an agent shows up using a human's account. The red teamer tries to make one agent impersonate another. GRC keeps the register that ties every agent to an owner. The responder uses that distinct identity to isolate exactly the one agent that went bad, and nothing else.

Why this is more than a nice feature

There is a hard reason the five-seat view matters, and it is in the data. A 2026 CSA survey found that ownership of agents is fragmented, split across security, IT, and AI functions, and that 84% of organizations doubted they could pass an audit of their agents' behavior. Fragmented ownership is exactly the condition where a control falls through the cracks: engineering assumes detection has it, detection assumes GRC has it, and nobody actually does.

A shared artifact that speaks to all five seats at once is a small antidote to that. When the engineer, the analyst, the red teamer, the GRC lead, and the responder are reading the same control, each in their own language, they are at least looking at the same thing. They can see where their work hands off to the next seat, and where it does not. That hand-off, the seam between two teams, is where agent security tends to break, which is the whole reason this matrix exists.

Use it

Open any control and pick your lens. If you build, read the engineering view and the steps. If you defend, read detection and SecOps. If you answer to an auditor, read GRC and go straight for the evidence. And every so often, read a control through a seat that is not yours, because the fastest way to understand why a control matters is to see who else is depending on you to get it right.

You can switch the persona view on every control at securitycontrols.ai.

Sources