Most of what the industry calls agentic security risk is exposure management, identity hygiene, and telemetry you already know how to run. What’s missing is not theory. It’s blueprints that someone can build from. I’ve been writing them, and more of us should.

The board and the SOC are describing the same risk in different languages

CISOs talk about risk in GRC terms because that’s what the board hears. SOC teams work from attacker behavior. Neither side can act on the other’s vocabulary.

So I put both on one grid. Eight board-level risk scenarios, from data leakage to model theft, sit on one side. On the other, I placed observed activity: six cases from Anthropic’s September 10 threat report, plus one from Microsoft’s reporting on device-code phishing. AI-orchestrated intrusion, malware rebuilt when detections fired, credential and token theft, mailbox exfiltration at scale. The placement is illustrative, not a risk score. The point is that the board’s top concerns, data leakage, unsafe decisions, and autonomous actions, are already showing up in real operations. None of it needs a new discipline.

That mapping is how you move a CISO. Start in the board’s language, then show where the categories overlap with problems they already fund. “This is as bad as that” changes minds faster than any framework.

Microsoft draws a big circle. It doesn’t cover the page.

Microsoft does some capabilities well. It gives partial signal on others. For policy design, workflow management, cataloging, specialist testing, and service management, it doesn’t get there.

Those gaps aren’t tool problems. They’re integration, workflow, and organization problems, the same ones SIEM teams have complained about for a decade. Microsoft still has no CMDB, and I don’t know why.

Your job is to decide what fills the gaps. If you anchor your career there, you’ll have work forever. Expect to bring in a third-party service management or ticketing tool. The moment vendors try to overlap several capabilities in one product, suddenly people think they’re delivering the whole workflow when they are delivering a tool.

What a blueprint looks like: agent identity and registry

Here is the pattern, kept deliberately short:

• One credential per agent blueprint: a federated identity credential with managed identity or a certificate. No client secrets in production.
• Child agents get tokens through the blueprint, by impersonation only.
• Conditional access and agent risk gate every issuance. This is the big change, and it’s what builds trust.
• Define consent geometry up front. Decide what the admin actually reviews when approving, and what inherits to future child agents.
• Pick one registry. Don’t run one per hypervisor, hyperscaler, or business group. Converge where most of your data already lives.
• Don’t hard delete. Disable, retain, and keep watching. If you assume an agent is gone, you’ve made a dangerous assumption. The Anthropic report describes malware that was rebuilt when detections fired.
• Log the task actor, meaning the orchestration layer behind the workflow: your SOAR, Logic Apps, or Power Automate. Treat its tasks like any other detection source.

This design gives you a threat model, a repeatable build, and the ability to reconstruct what an agent decided and why. Store it as code in the same repo as your AI infrastructure and anyone can test it later.

Design for failure, not for the demo

Four things I missed in my first round of blueprints:

1. Which judgment is being delegated. Stopping at a red light is five judgments: see the light, lift off the gas, press the brake, hold the wheel, check the road. If you can’t say which one the agent owns, the delegation is too vague.
2. What the system can do without approval. “Everything already granted” is the wrong default for enterprise security. Allow-list thinking is painful, as anyone who ran Carbon Black Protect remembers, but it points the right way.
3. What must be recorded and attributable. Walk a multi-agent investigation as a tabletop and write down what you wish you had logged.
4. What happens when telemetry or confidence disappears. Attackers look for where your telemetry isn’t reporting. If a compensating control is the reason you didn’t catch something, you also need to know when that control goes dark.

Every autonomous loop needs the same things: a start condition, triggers, and stop conditions. An agent that keeps cycling on missing fields and bad data is the failure mode people get angry about.

Measure what changes a decision

You don’t have to invent KPIs. Track the share of agents with a named owner, consequential actions behind approval gates, telemetry coverage, responses you can reconstruct, incident pathways you’ve tested, and how fast exception requests get an answer. Slow exceptions push people to route around you. If a metric doesn’t change a decision, a control, or a priority, stop collecting it.

What to do now

The worst move in this transition is keeping patterns to ourselves. Pick a use case nobody has written up, such as misuse, policy bypass, or data sovereignty, and write the blueprint. Make it buildable and testable, and small enough that people actually adopt it. Want to co-create? Reach out.