A one page coding agent policy should say which tools are approved, what data may enter them, how agent written code is reviewed and labelled, what is off limits, and who to contact when something goes wrong. Plain words, short sentences, one owner. If it needs a lawyer to read, nobody will.
Why one page
Long policies are signed and forgotten. A single page can be pinned in the repository, quoted in a pull request, and read in two minutes. The detailed controls live in tooling and settings, and the page explains the human parts.
The seven sections
1. Approved tools. Name them and link to the setup guide. Anything else needs a request through your exceptions route.
2. What you may share. Source code in approved repositories, yes. Customer data, credentials, and personal data, never. When unsure, ask before pasting. OWASP lists user education and clear data handling policies among its mitigations for sensitive information disclosure, and this section is where that lives.
3. What the agent may do. Read the project, write on a working branch, run listed commands. No production access, no direct push to the default branch.
4. Review. Every agent change gets a human reviewer who did not launch the agent. You remain responsible for what you submit.
5. Labelling. Agent assisted commits carry the agreed trailer. See how to label agent written commits.
6. Off limits. List the repositories and tasks that are human only for now, such as authentication, signing and deployment code.
7. When something goes wrong. Who to contact, how to stop the agent, and what to do if a secret was exposed: rotate it and tell security. No blame for fast reporting.
Template wording
Use short lines such as these, then adapt them.
- Use only the approved tools listed on this page.
- Never paste credentials, customer data or personal data into an agent.
- Review every agent change as if a stranger wrote it.
- Do not give an agent access to production.
- If an agent does something unexpected, stop it and report it the same day.
Rollout steps
- Draft with one developer and one security engineer.
- Test it on three developers who did not help write it. Ask what was unclear.
- Publish it where developers already look, not in a policy portal.
- Review it every quarter, or when tools change.
- Pair it with a ten minute walkthrough, not an annual course.
What to leave out
Legal boilerplate, vendor comparisons, and long rationale. Put those in a separate reference. A policy that tries to teach, justify, and enforce at once does none of the three well.
Keep it honest
Do not promise controls you have not built. If logging is partial, say what is logged. Developers notice gaps, and a policy that overstates loses credibility quickly. For a longer baseline of controls, see the week one controls.
Safeguard offers policies, gates and guardrails that turn several of these rules into checks, and compliance and evidence automation to record that they ran.
Quick check
Should the policy name specific tools?
Yes, as an approved list that is easy to update, so the policy text itself stays stable.
Do contractors follow the same page?
Yes, and confirm they have read it before access is granted.
Sources
Last reviewed: 19 October 2026.
