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 and per pipeline stage, so a coding agent's credentials match exactly what its current stage requires rather than a broad, pipeline-wide grant carried across every job. Execution runs inside sandboxed boundaries, containing what an agent can reach even if it attempts to go beyond its assigned task.
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. Full audit logging captures every tool call and every file or shell action for post-incident review, attributable to the specific agent and run, which turns "we think this is what happened" into a record a security team can actually verify. 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.