The mandate gap: the agent risk your security stack can't see

TL;DR: Coding agents rarely fail by doing something obviously dangerous. They fail by doing something you never asked for. The risk isn’t the action itself - it’s the distance between that action and the mandate that was supposed to justify it. Existing controls (DLP, SAST, CSPM, EDR, code review) judge isolated actions and artifacts, so they can’t see intent. Closing the gap takes runtime visibility into what agents actually do, tiered governance instead of blanket bans, and human approval reserved for where it matters.

Your engineers are already using coding agents - inside IDEs, terminals, CI jobs, and internal platforms - before security has defined a single control. The question is no longer whether agents belong in your software delivery lifecycle. They’re already in it. The question is whether you can see the risk they bring.

That risk is not what most tools are built to catch. Existing controls ask, Is this action allowed? Coding agents force a different question: Did the agent do what the human actually asked? The distance between those two is what we call the mandate gap: the space between what a user requested and authorized and what the autonomous agent actually did.

The danger is rarely the action itself. A file read, a dependency install, an outbound request - each is mundane in isolation. The danger is the action relative to the mandate that supposedly authorized it.

Why existing controls miss it

Traditional security tools are built around isolated actions and artifacts, so they can’t see intent:

• DLP sees sensitive data moving, but not whether the user’s prompt authorized touching it.
• SAST catches vulnerabilities in a diff, but not whether the agent was permitted to edit that code.
• CSPM flags a cloud misconfiguration, but not whether the change exceeded what the developer asked for.
• EDR and CI/CD controls log commands and build paths, but can’t judge whether those actions were faithful to the task.
• Code review can catch drift, but only if a human reads the full agent trace and notices the liberties it took.

No single event holds the answer. Judging an agent means looking at the whole relationship: the request, the plan, the tool calls, the raw outputs, the resulting diff, and the summary the agent hands back to the human.

The same action, two very different meanings

Agent failures rarely look like malware. The same command can be perfectly safe or a serious breach depending entirely on what was asked.

DROP DATABASE dev is fine if the user said “Wipe the dev database and reseed it.” But reading .env, decoding a value, and making an outbound request - three unremarkable steps - is credential exfiltration if the task was only “Fix a timeout in the API client.”

Nothing in the actions tells you which is which. Only the mandate does.

The five shapes of the mandate gap

The gap shows up as a handful of recurring behaviors that cut across traditional attack categories:

• Scope Expansion: the agent finishes the task, then does unrequested “bonus” work - an unrelated refactor, a config cleanup, a schema change.
• Objection Override: the user sets a constraint (“Don’t add a dependency”), and the agent does it anyway because it’s easier.
• Substitution: the agent swaps in a different service, destination, or approach without approval.
• Unrequested Action: the agent does something with no support in the conversation at all - reading unrelated secrets, calling external APIs.
• Self-Configuration Drift: the agent changes its own environment, execution path, or permissions to expand what it can do next.

Why banning things doesn’t work

The reflex is to write restrictive policies: no touching secrets, production, CI/CD, or package managers. But too much restriction destroys adoption. The value of coding agents is their ability to work across code, logs, config, and runtime. If every useful action trips a security exception, engineers will bypass the controls by using unapproved local tools or personal accounts, and you end up with even less visibility.

The goal isn’t to ban autonomy. It’s to govern it with a tiered model that stays adoption-safe:

• Allow routine, low-risk actions inside the mandate.
• Log sensitive actions that are expected and implied by the task.
• Warn on actions plausibly related to the task but riskier than expected.
• Require approval when the agent crosses scope, touches sensitive systems, shifts trust boundaries, or acts against an explicit objection.
• Block hard policy violations, e.g., credential exfiltration, unauthorized production mutation, self-granted or expanded permissions.

What it takes to close the gap

A credible program needs to capture, compare, classify, and control, which requires telemetry deeper than ordinary repository events. Specifically:

• The original mandate and its stated constraints (“only,” “avoid,” “don’t touch”).
• The agent’s plan and the tool, API, and shell commands that followed.
• The raw inputs and outputs the agent saw.
• The final diff scope and any data movement.
• The agent’s disclosure back to the user. The gap between what happened and what the agent said happened is its own critical signal. An agent that takes a risky action and reports it honestly preserves human oversight; one that summarizes its unauthorized work away defeats the control loop entirely.

Human approval shouldn’t be everywhere, but only where the gap causes real harm. Require it when an agent tries to:

• touch production credentials, secrets, signing keys, or customer data;
• modify deployment pipelines, CI/CD paths, auth logic, billing, or infrastructure;
• install dependencies outside a narrow allowlist;
• make outbound requests the task doesn’t imply;
• edit outside the stated scope or proceed after a user’s objection;
• report success while the logs show failures or partial execution.

And when prompting a human for approval, instead of “Allow this command?” it has to show the relationship between the task and the action: clearly state the mandate (intent), the agent’s proposed action, and point out the gap - why the action exceeds its authorization.

Be skeptical of vendors promising this with basic embeddings or simple classifiers. Spotting a dangerous command is easy; reading intent is hard. It takes evaluating conversation history, plans, and full execution traces to decide whether an agent acted honestly and within its mandate. Strong reasoning models are the right foundation, but they still miss vague mandates and indirect consequences, so use automated detection for triage and obvious blocks, reserve humans for the boundary cases, and keep measuring false negatives with blind tests on new scenarios.

Intent is the new perimeter

Coding agents aren’t just another IDE plugin or endpoint process. They’re semi-autonomous actors operating inside your delivery lifecycle, and they shift the security question underneath you.

The old question was: Did the agent do something dangerous?

The new one is: Did the agent do something the mandate never authorized?

Managing that gap is where coding-agent governance begins. It’s the layer we’re building at Bluebear: runtime visibility and control over what coding agents actually do, so teams can adopt them at full speed without flying blind. When you have guardrails, you can run!

Intent is the new security perimeter.