300 m
The delivery team
Guardrails are a team decision
When a large team starts using AI agents to write production code, the first instinct is to share prompts. Somebody builds a clever one, it goes in a channel, and everyone copies it with small variations. Within a month there are thirty prompts and no agreement on what the agent is allowed to touch. The prompts were never the problem. The missing boundaries were.
Decide the guardrails as a team before the tooling spreads. Which directories can an agent edit, which commands can it run, and which changes always need a human to write the first line? Settle it once, put it in the repository, and review it like any other code. Tech leads own the file. Everyone else gets to argue in the pull request.
Ground
The code
Make the rules executable
Guardrails that live in a slide deck are suggestions. At ground level they need to be configuration the agent actually reads, backed by a pipeline that fails when the rules are broken. Most agent tooling now supports a project settings file. Use it to deny the obvious hazards, such as profiles, permission sets and production deployments, and to require the same checks a human would face.
# .agent/policy.yaml
deny_paths:
- force-app/main/default/profiles/**
- force-app/main/default/permissionsets/**
deny_commands:
- sf project deploy start --target-org prod*
require_before_commit:
- npm run lint
- sf apex run test --test-level RunLocalTestsThen test the guardrails the way you would test anything else. Ask the agent to edit a profile and check that it refuses. Ask it to skip the tests and check that the commit fails. If the only thing stopping it is good manners, you do not have a guardrail. You have a hope, and hope is not a control.
