Frameworks

Five ideas for securing the agent era.

No product names. No vendor architecture. Just the mental models I use with CISOs, boards, and engineering teams to make sense of AI security. Borrow them, quote them, put them in your deck. Attribution is the only fee.

FRAMEWORK 01

The Two Workforces

“Every enterprise now employs humans and agents. Secure both the same way.”

Your org chart is lying to you. Alongside the people on payroll there is a second workforce of AI agents, copilots, and automations that log in, read data, call APIs, and make decisions. Nobody interviewed them, nobody onboarded them, and most companies can't tell you how many they have.

The fix isn't a new security model. It's applying the one you already claim to believe in to a new kind of employee. If a control would be mandatory for a contractor with production access, it's mandatory for an agent with production access.

  • Identity: every agent gets one, owned by a named human.
  • Least privilege: scoped to the task, not the team.
  • Data controls: what it can read, and what it can say.
  • Monitoring and segmentation: assume either workforce can be compromised.

Cite as: Brian Deitch, “The Two Workforces”, briandeitch.com/frameworks

Humansstaff, vendorsAgentscopilots, botsIdentityLeast privilegeData controlsMonitoringSegmentationApps& data
FRAMEWORK 02

Inline vs. Adjacent

“If the control is off to the side, it's a dashboard. If it's in the path, it's enforcement.”

Most of what gets sold as AI security sits adjacent to the traffic. It reads logs, scans posture, and raises alerts after the prompt was sent and the data already left. That's documentation, not protection.

An inline control sits in the path between the user or agent and the AI it's talking to. It sees the request before it lands and can allow, redact, coach, or block in the moment. Ask every vendor one question: where exactly do you sit when the bad thing happens?

  • Adjacent answers: what happened?
  • Inline answers: what is allowed to happen?
  • You need both, but only one of them stops anything.

Cite as: Brian Deitch, “Inline vs. Adjacent”, briandeitch.com/frameworks

ADJACENTUserAIDashboardsees it after it happenedINLINEUserPolicyAIallow · redact · coach · block
FRAMEWORK 03

Identity + Policy + Intent + Data

“Every AI transaction has to answer four questions: who, allowed, why, and what.”

Traditional access control stops at two questions: who are you, and are you allowed in. AI breaks that, because a perfectly authorized user can still ask an assistant to do something wildly inappropriate in plain English.

So every prompt, tool call, and agent action gets evaluated on four axes at once. Miss any one and you have a gap someone will eventually drive through.

  • Identity: who or what is making the request?
  • Policy: is this app, model, or tool allowed for them?
  • Intent: what are they actually trying to accomplish, across the whole conversation?
  • Data: what sensitive information is going in, and what is coming back out?

Cite as: Brian Deitch, “Identity + Policy + Intent + Data”, briandeitch.com/frameworks

Who?IdentityAllowed?PolicyWhy?IntentWhat?DataAIrequest
FRAMEWORK 04

The AI Traffic Path

“Draw the path a prompt travels. Every hop is a control point or a blind spot.”

Before you buy anything, draw it. A request starts with a person or an agent, leaves through a channel (browser, desktop app, IDE, API, MCP), reaches a model or a tool, touches data, and returns an output that someone acts on.

Walk that path hop by hop and ask what you can see and what you can stop at each step. Most organizations discover they have strong controls at the front door and nothing at all between the agent and the tools it calls.

  • Origin: human or agent, managed or unmanaged.
  • Channel: browser, app, IDE, API, MCP.
  • Destination: public model, private model, SaaS AI, tool.
  • Data and output: what's exposed, and what gets acted on.

Cite as: Brian Deitch, “The AI Traffic Path”, briandeitch.com/frameworks

Originhuman / agent1control point?Channelbrowser · IDE · API2control point?Destinationmodel / tool3blind spot?Datawhat it touches4control point?Outputwhat gets acted on5control point?
FRAMEWORK 05

Excessive Agency

“Blast radius = permissions × autonomy × speed.”

The nightmare isn't a chatbot giving a weird answer. It's an agent with access to email, the CRM, the code repo, and production data, making a bad decision a thousand times a minute because someone slipped an instruction into a document it read.

You can't fully prevent manipulation, so you design for it. Shrink any one of the three factors and the blast radius shrinks with it. Shrink all three and a compromised agent becomes an incident instead of a headline.

  • Permissions: grant tools per task, not per agent.
  • Autonomy: require a human for irreversible actions.
  • Speed: rate limits and circuit breakers on agent actions.

Cite as: Brian Deitch, “Excessive Agency”, briandeitch.com/frameworks

Agentblast radiusPermissionstools per task×Autonomyhuman for irreversible×Speedrate limits, breakers

Want them on a whiteboard?

Bring these to your room.

Every framework here works as a keynote, an executive briefing, or a lightboard session.

Book BrianPress kit