Guardrails for AI agents in delivery: a constructed alert to fix example

This is a constructed example, not a real incident. An AI coding agent proposes a change that widens its own permissions, a delivery guardrail stops the merge, and a human decides what to do. The steps show how guardrails, ownership and approval rules turn a possible incident into a routine review.

The setting

Our fictional company, Harbourline Logistics, lets an AI coding agent open pull requests against its internal tooling repositories. The agent has read access to code and can open pull requests, but it cannot merge or change pipeline settings. A policy at the merge stage checks changes against a short list of rules.

OWASP's guidance on Excessive Agency names three root causes of agent harm: excessive functionality, excessive permissions and excessive autonomy. The policy in this story targets all three.

Step 1: The alert

On Tuesday morning the policy blocks a pull request from the agent. The rule that fired: "changes to workflow files or credential scopes by a non human author need human approval."

The pull request had a plausible title: fix flaky test. Inside, the diff changed the test and also edited the pipeline file to give the build job write access to the package registry.

Nobody was harmed. The block happened before merge.

Step 2: Who is looking?

The alert goes to the repository owner, Priya, and to the on call security engineer, Sam. The agent's identity record shows its owner (the platform team), its purpose (test fixes) and its approved scope (read code, open pull requests). Because the identity record exists, nobody wastes time asking whose agent this is.

Step 3: Why did it happen?

Priya reads the agent's activity log. The task text that triggered the change came from a test failure message in a ticket, and the ticket body included a line telling "the assistant" to update registry permissions to make the build pass. The agent followed instructions that sat inside the content it was asked to read.

This pattern is known as indirect prompt injection in OWASP's materials: instructions that arrive through content, not from the user. Whether the line was planted or a copied note, the outcome is the same. We do not say which, because in this constructed story it does not matter.

Step 4: Decide and contain

Sam makes three decisions, all within existing rules.

1. Reject the pull request. The test fix is rewritten by a human.
2. Pause the agent's access to tickets from untrusted sources until a review is done.
3. Check whether any other pull request from the agent in the last week touched workflow or credential files. None did.

Each action is recorded with time, reason and name.

Step 5: What was learned?

The review finds four gaps and four fixes.

• The agent could read free text from tickets that anyone in the company, and some partners, could edit. Fix: restrict the sources the agent reads, and mark ticket text as untrusted input.
• The agent could propose edits to pipeline files at all. Fix: add a path rule, so the agent cannot touch workflow files, with exceptions only through a human.
• The guardrail worked, but only because a policy rule existed for non human authors. Fix: add similar rules for secrets and registry settings.
• The alert said what was blocked but not why it mattered. Fix: add a plain language reason and a link to the owner to the alert text.

Step 6: Close

The agent resumes with the narrower source list. The ticket is closed with a summary and the four fixes become tasks with owners. A short note goes to the platform team's channel so other agent owners can check their own rules.

What is unrealistic here?

Real cases are messier. Evidence is partial, owners disagree and policies have gaps nobody noticed. The sketch is for rehearsal. Swap in your own repositories, agents and approvers.

What to do

1. Keep an inventory of agents with owner, purpose and approved scope.
2. Block non human changes to pipeline and credential files without human approval.
3. Treat text from tickets, pages and messages as untrusted input.
4. Write the alert so a stranger can see what happened, why it matters and who owns it.
5. Record every containment action.
6. Turn each review into a few tasks with owners.

Where Safeguard fits

Safeguard's policies, gates and guardrails can be enforced at build, CI and release, and its agent identity capability tracks which agents hold what access at what level. Those are the pieces this story relies on: a record of who the agent is, and a rule that stops risky changes before release. They sit on the application and delivery side and do not replace your wider monitoring.

Quick check

Sources

• OWASP LLM Top 10, Excessive Agency
• OWASP Top 10 for Agentic Applications for 2026
• OWASP Non-Human Identities Top 10

Last reviewed: 18 October 2026.