What this looks like in practice
The problem
A coding agent with shell and filesystem access in a CI/CD pipeline will, by design, use every capability it's granted — including ones nobody meant to leave open. Pipeline credentials are typically broad, long-lived, and shared across many jobs, which means one compromised or misdirected coding-agent run has a blast radius across the entire build system, not just the task it was assigned.
Platform teams that adopt coding agents fast, to keep up with how quickly the tooling is moving, often inherit this problem directly: the credentials the agent runs with are the same broad service-account credentials a human CI job already used, because narrowing them per agent and per stage was never built into the rollout.
What good looks like
A well-governed coding-agent pipeline scopes access down to exactly what a given stage needs: a build stage gets access to the repository and build tools it touches, a deploy stage gets access to the deployment target and nothing else, and no single credential spans the whole pipeline by default. Execution happens inside a sandboxed boundary, so even if an agent attempts an action outside its intended task, the boundary — not the agent's own judgment — is what stops it.
The capability surface is explicit and enforced rather than implicit: what the agent can call, read, and write is a defined, reviewable list, not an emergent property of whatever the underlying shell or filesystem access happens to allow. And every tool call, file write, and shell command the agent executes is logged in a way that's attributable to the specific agent and pipeline run, so a post-incident review can reconstruct exactly what happened without piecing it together from partial CI logs.
How Praesidia helps
Praesidia scopes tool access per agent, so registering one agent per pipeline stage gives each stage its own grant — the deploy-stage agent holds only what deploying requires — rather than a broad, pipeline-wide grant carried across every job. Praesidia does not sandbox the agent's runtime: process, filesystem, and network isolation come from your CI runner or sandbox. What it adds is a policy check on each tool call that passes through it — a tool-policy rule set to enforce denies an out-of-scope call before the tool runs, while a rule in audit mode, the default for new rules, records the would-be denial without blocking.
The capability surface an agent operates within is explicit and enforced, not an implicit consequence of whatever shell or filesystem access the underlying environment happens to expose — so platform teams can review and reason about exactly what a coding agent is capable of doing before it runs. Tool calls that pass through Praesidia are recorded for post-incident review, attributed to the agent and, for calls made within an agent task, to that task. Praesidia records its policy decisions in the append-only, hash-chained audit trail, signed under the default configuration (an operator can turn signing off), which turns "we think this is what happened" into a record a security team can check. File or shell actions the agent takes outside Praesidia are not recorded. The AI agent security guide covers the broader control set — identity, guardrails, sandboxing — this use case draws from.
Getting started
- Map current pipeline credentials against pipeline stages — identify every place a single credential spans more stages than it needs to.
- Scope the highest-risk stage first — typically deploy or any stage with write access to production — down to least privilege before addressing lower-risk stages.
- Sandbox execution boundaries around the coding agent's runtime, so out-of-scope actions are blocked structurally rather than relying on prompt-level instructions.
- Define the capability surface explicitly: which tools, which shell commands, which file paths the agent can touch, reviewed the way you'd review a permission grant for a new service.
- Confirm audit logs actually answer "what did this agent do in this run" before an incident forces you to find out they don't.
FAQ
What is the smallest credential a coding agent can work with? One scoped to exactly the repositories, branches, and shell or filesystem operations the current pipeline stage requires — not a broad, long-lived credential shared across every job in the pipeline.
How do we contain a coding agent that goes beyond its task? A sandboxed execution boundary and an explicit, enforced capability surface stop an out-of-scope action before it executes, rather than relying on the agent to stay within its intended task.
What should a pipeline log for post-incident review? Every tool call and every file or shell action the agent took, attributable to the specific agent and pipeline run, so a review can reconstruct exactly what happened without guesswork.
Securing AI agents in CI/CD pipelines and securing AI coding agents cover the broader threat model this use case addresses; tool-use safety and sandboxing and implementing least privilege for agents go deeper on the two capabilities this page depends on most.