What is Agent Execution Governance?
Agent Execution Governance (AEG) is the enforcement layer between AI agents and real systems. It evaluates every action an agent attempts — each tool call, shell command, API mutation — against deterministic policy at execution time, and either passes it, blocks it with an explanation, or holds it for human approval. The defining property: enforcement happens before the action executes, and every decision traces to a rule a human wrote or approved.
Why the category exists
AI agents don’t know your security, infrastructure, or compliance constraints — and prompts are not boundaries, they are suggestions. An agent with write access will eventually attempt something destructive: a schema migration against production, a force-push over a protected branch, a terraform destroy it sincerely believes solves the task. Two existing tool categories fail to prevent this, for opposite reasons:
- Prompt-level guardrails (system prompts, rules files, LLM judges) are probabilistic. They shape behavior; they cannot guarantee it. A control that fails one time in a thousand is not a security boundary.
- Observability (Datadog, Sentry, PagerDuty) is post-incident by construction. It has no authority over an action before it executes — it can only tell you what already happened.
AEG fills the gap the way IAM did for humans: not by making the actor smarter or the telemetry richer, but by putting an enforcement point between the actor and the system.
The three properties that make a system AEG
- Deterministic enforcement. The pass/block/hold decision comes from explicit rules, evaluated in-line and fast (Mergen: under 1ms, no LLM in the critical path). Identical input, identical verdict — which is what makes the system auditable and testable.
- Human-in-the-loop escalation. Ambiguity routes to a person, not to a guess. Risky calls suspend until a verified human approves or denies — and unanswered holds fail closed. Intelligence (scoring, similarity, behavioral analytics) may raise scrutiny toward a hold; it never produces a block or a pass on its own.
- Accountable memory. Every decision — human overrides included — is recorded and becomes enforceable policy. The system gets stricter where your team has been burned, and it can prove to an auditor exactly why any action was allowed or stopped.
Where enforcement physically happens
Agents act through defined channels — MCP tool calls, IDE tool hooks, CI pipelines — and the enforcement point isn’t the same for all three. A local MCP proxy intercepts each tools/call before the handler runs, and an IDE hook gates built-in tools like Claude Code’s Bash, the same way: the gate runs on your infrastructure, the agent’s task continues minus the hazardous step, and a blocked call returns a structured “why, and what to do instead,” so the agent reformulates within policy. A CI gate is different in kind: it evaluates an agent-generated pull request’s diff before merge and returns a verdict — Mergen doesn’t control whether that PR can actually be merged. That decision belongs to the repository’s own branch protection rules, which have to be configured to require the gate’s check before a flagged change is physically stopped from merging.
| Gate | Enforcement point | Controlled by |
|---|---|---|
| MCP tool calls / IDE hooks | Local runtime, pre-execution | Mergen |
| CI gate (pull requests) | GitHub mergeability | GitHub required status checks + branch protection |
That doesn’t make the CI gate weaker — a heuristic, pre-merge check on a whole diff is a different job than a millisecond veto on one tool call, and it’s the right shape for that job. It means the trust boundary is explicit: Mergen enforces MCP and IDE tool calls directly; it evaluates pull requests and lets your existing GitHub configuration enforce the outcome.
AEG in one sentence
Rules enforce. Intelligence advises. Humans decide — and all of it happens before the action executes, not in the postmortem.