In 90 days a small team can put real guardrails on its AI agents and delivery pipelines: list every agent and what it can reach, cut access to what each task needs, log every tool call, require approval for irreversible actions, and review the results monthly. Start with access, because that is what limits damage.
Days 1 to 30: find out what exists
Week 1: inventory agents. Ask each engineer which AI assistants, coding agents and automations they use, and check code repositories, CI settings and tool server configurations for agent keys. Record the owner, purpose, tools used and credentials for each. Expect to find some nobody mentioned.
Week 2: map access. For each agent, write what it can read, write, delete and deploy. Note whether it uses its own credential or a person's. A shared personal token is the first thing to fix.
Week 3: map pipelines. List the steps from commit to production, who or what can approve each, and which checks run. Mark steps where a failing check does not actually stop anything.
Week 4: pick three rules. Choose rules you can describe in a sentence and enforce, such as "agents cannot merge to main," "no new dependency from an unknown registry," and "production deploys need a second approver."
Days 31 to 60: enforce in the safest order
Reduce access first. Move agents to their own credentials with the narrowest scope that works. Give code agents read access and the right to open pull requests, not to merge. Remove secrets from environments where an agent runs.
Add logging. Record each tool call with the agent identity, time, action and outcome. Send logs where the team already looks. You cannot judge a guardrail without evidence of what happened before and after it.
Run the rules in warn mode. For two weeks, let the three rules report violations without blocking. A constructed finding: a build agent tried to fetch a package from a registry outside the allowed list four times. That is information you want before you turn on blocking.
Add approvals. For actions that are hard to undo, such as deleting data or deploying to production, require a named human yes.
Days 61 to 90: switch to blocking and make it routine
Turn on block for the top rule. Pick the rule with the clearest value and fewest false alarms. Announce it, publish the exception process, and be ready to fix breakage quickly.
Test the limits. Try, in a test environment and with permission, to make a test agent exceed its access, for example by giving it a file containing instructions to read a secret. Defensive testing like this shows whether a prompt is the only thing between the agent and the secret. If it is, you have not built a guardrail yet.
Set a monthly review. One hour: new agents found, rules triggered, exceptions granted, access changes. Retire agents that nobody uses.
Write the summary. One page for leadership: what exists, what is enforced, what is next. Be plain about what is still open.
Traps to avoid
- Writing a long policy and enforcing nothing.
- Blocking before you have watched in warn mode.
- Giving an agent admin rights "just to get started."
- Forgetting that third party tools and plugins run with the agent's access.
Where Safeguard fits
Safeguard provides policies, gates and guardrails that can be enforced at build, CI and release, an MCP Guardrail that works as a proxy for MCP servers, and tracking of agent identity, meaning which agent holds what access at what level. Autonomous remediation, which creates fix pull requests, is off by default with categories starting on manual approval. An AI Gateway or LLM firewall is in early access. You can follow this plan with your own tools too; the steps matter more than the product.
What to do
- By day 7, list every agent, owner and credential.
- By day 30, write three enforceable rules and move one agent off a personal token.
- By day 45, have tool call logging in place.
- By day 60, run the rules in warn mode and review violations.
- By day 90, block on the top rule, test limits and hold the first monthly review.
Quick check
What is the first guardrail to put in place?
Reduce agent access to what the task needs, using the agent's own scoped credential rather than a person's token.
Why run rules in warn mode first?
It shows what would be blocked and avoids breaking legitimate work, so you can tune before enforcing.
Sources
This plan reflects general engineering practice. No external standard was fetched for it, so check your own policies and current vendor documentation for tool specific settings.
Last reviewed: 18 October 2026.
