Governing AI agents across the SDLC: from prompt to merged PR

SDLC governance for AI agents means deciding, at every stage where an agent can act, whether that action is allowed, and keeping a record of the decision and of the action. The stages are the same for every team: local edit and shell, MCP tool calls, commit, push, pull request, CI, deploy, and the cloud runtime an agent may run inside.

Most programs we look at have two of the five parts of that. They have some inventory and a policy document. What they are missing is a decision taken at the moment of the action, and evidence that survives the laptop it happened on.

The five parts

Part	The question it answers
Inventory	Which agents, CLIs, MCP servers and models are on this machine, and at which version
Policy	Under what conditions may this agent take this action, here
Gate	A deterministic check that one action cannot pass until a condition holds
Approval	A named person accepting one specific risky action, once
Evidence	An ordered record of what the agent did and what was decided, exportable and verifiable

The eight stages, and who can decide at each

Stage	What the agent does there	Control that can decide	What that control cannot see
Local edit and shell	Writes files, runs commands	Vendor hook, or an endpoint policy service	The other agents and tools on the same machine
MCP tool calls	Calls stdio or remote servers	The endpoint, before the call executes	Nothing at the call, but stdio servers never reach a gateway
Commit	Stages and commits changes	pre-commit git hook	Anything the agent did before staging
Push	Sends refs to the remote	pre-push hook, then server-side rulesets	The session that produced the commit
Pull request	Opens or updates a PR	Rulesets, required checks, CODEOWNERS	Whether the author was an agent or a person
CI	Builds, tests, may assume cloud roles	Workflow permissions, OIDC trust policy	Actions taken before CI started
Deploy	Ships a revision to production	Environment reviewers, deployment protection rules	Whether the change matches the story around it
Cloud runtime	Runs the agent inside your cloud	The runtime definition and its egress policy	Laptops outside that runtime

Local edit and shell

The agent can change files and run commands here, and the record of those actions is often thin. Every major vendor now ships a hook on the request path. Claude Code fires PreToolUse before a tool call and honours a JSON reply with permissionDecision: "deny" (hooks reference). Cursor runs beforeShellExecution and beforeMCPExecution hooks from hooks.json, blocks on exit code 2, and fails open on a crash or timeout unless the hook sets failClosed: true (hooks reference). Codex decides when to pause through approval_policy in ~/.codex/config.toml and limits the blast radius with sandbox_mode (config basics, sandbox and approvals).

Those are worth deploying, and they have three limits. Each hook speaks for one vendor, so three agents mean three config files and three scripts that drift apart. Hooks are client-side. A developer who is an administrator on the machine can edit the settings file itself, and Anthropic's own docs say server-managed settings operate as a client-side control, not a security boundary, because on an unmanaged device a user does not need admin access to bypass them (server-managed settings). A hook decision is also local to that client unless you export it, and Claude Code can export tool decisions over OpenTelemetry when you point it at a collector (monitoring).

An endpoint agent is the layer for this stage because it sees all the agents at once. Alyria Beacon inventories the AI toolchain on each machine and evaluates Lyra policy on every model and MCP call locally, and it deploys read-only with policies in monitor mode, so you can watch the decisions before any of them stop work (rollout).

MCP tool calls

Most MCP governance content is written for gateways, which govern what is routed through them. A stdio server is a child process on a pipe; nothing crosses the network, so a gateway has nothing to log. The call is still observable where it originates.

Policy at this stage is rarely a tool allowlist. The interesting rules depend on the call: which server and tool, which arguments, what class of data the request carries, and what the session already read. Lyra is deny-by-default with explicit capability grants, and it tracks data classification as it moves through the agent's context, so a tool can be allowed in general and one call still denied (Lyra policy as code).

Commit and push

pre-commit and pre-push are files in .git/hooks, and both can be skipped: git commit --no-verify and git push --no-verify do it (githooks). Treat them as help for the developer, not as the gate. The enforced version lives on the server: a ruleset or protected branch that requires a pull request, requires status checks to pass, and requires a review (protected branches).

What the server cannot see is intent. It sees a commit, not that the agent fetched a fix from the web twenty minutes earlier, or read a .env file, or edited a test to match its own bug. Sequence rules close that gap, and they are cheap because they only need a few flags per session. Alyria publishes worked examples of that shape on semantic policy examples, including the one this stage most needs: after a web search in a task, a push requires a passing review.

Pull request

The pull request is the first point where a second person sees the change, and the first boundary where a slow check is acceptable, because only the merge waits. Required status checks and required reviews are long-standing controls. The agent-specific questions are narrower: may the agent open the PR (usually yes), may it push more commits after review (usually only with a fresh review), may it merge (usually no).

CI

CI runs the change under its own execution identity, with its own network and credential scope. Restrict workflow permissions: to what the job actually needs, and have the job assume a short-lived cloud role through OIDC instead of holding a stored key (OIDC in AWS). A self-hosted runner is production infrastructure, because it holds the credentials the workflow can reach.

Deploy

The deploy boundary is the last deterministic gate before customers see the change, and the clearest place to put a human. GitHub environments support required reviewers and deployment protection rules (managing environments). The action being approved is a release, which is easier to justify than an approval on every tool call.

Cloud runtime

When the agent runs in the cloud, the runtime itself is the control point. Statio runs the agent on an Alyria Beacon-governed node, on EC2, ECS or Kubernetes, so every model and tool call passes Alyria Beacon and Lyra on that node before it executes (Statio). The run is declared in the repository, in .alyria/agentcontainer.json, which states the image and harness, the model, the isolation and resource limits, the egress it may use, the MCP servers it may call, the external actions it may take, and the policies that apply to it. Keeping that declaration in the repository means a change to what an agent may do is reviewed like any other configuration change.

There is no hook to install inside the container and no sidecar for the agent to route around, which matters for framework agents that call providers through their own libraries. The boundary is the environment the agent executes in.

How the pieces line up

Alyria Beacon is the endpoint layer: inventory, local policy decisions, three enforcement planes that start in monitor mode. Lyra is the policy: capability grants, information flow, and sequence rules. Statio is the runtime for agents that should not run on a laptop. Observatory is the console where the fleet, the decisions and the posture sit in one place, and Spectra streams the signed decisions on to a collector you own. Every decision is signed and chained, which is what makes the record verifiable later rather than merely present (audit export).

The order that wastes the least time

1. Inventory first. You cannot write a policy about tools you have not listed.
2. Ship policy in monitor mode and read the decisions, not the dashboard counts.
3. Put gates at the boundaries that can wait: push, pull request, deploy.
4. Add approvals for the small set of irreversible actions.
5. Promote endpoint rules to enforce once the decisions have been right for a couple of weeks.

The rest of this series takes one part at a time: what evidence to record, where to put gates, and how to require human approvals without approval fatigue.

This post covers the Claude Code hooks reference, the Cursor hooks reference at schema version 1, the Codex configuration and approvals docs, and GitHub rulesets and environments, all read in November 2026. The vendor details will age. The stage map will not, because an agent has to get from a prompt to a merged pull request the same way a person does.