Ship an AI agent governance policy before agent number one touches production, not after agent number six deletes a customer's invoice history. That is the sentence security teams say out loud in July 2026 and mean it, because most companies handed Claude Code to engineering the same way they handed out laptops: no written policy for what the agents are allowed to touch, no inventory of who is running what, and no line in the incident response runbook for 'an agent did this.' The rollout works fine for six weeks. Then an engineer asks an agent to 'clean up the staging config' and it walks straight into a prod credential nobody scoped it out of, and the first question in the postmortem, what was this agent allowed to do, has no answer because nobody wrote it down.
The second problem sits underneath the first: shadow AI usage nobody in security knows about. IT provisioned five Claude Code seats for the platform team in Q1. By July, feature branches show agent commits from teams that never asked for access, PR reviews show agent-authored comments security never approved, and a Slack search for 'claude code' turns up two dozen threads where individual engineers wired their own MCP servers into internal tools with no logging and no offboarding hook. You cannot govern what you cannot see, and most companies discover how much shadow AI they are running only when a governance policy forces the inventory in the first place.
The third problem shows up during the next real incident. The runbook has a severity ladder for human error and a severity ladder for system failure. It has no path for an agent that had legitimate credentials, took a legitimate-looking action, and caused a legitimate mess, because the incident response plan was written before anyone assumed an autonomous agent would be the actor on the other end of a change. Writing the policy after the incident is how you end up explaining to a board audit committee why the answer to 'who approved this agent's access' is a shrug.
Why ChatGPT and Cursor cannot write this policy for you
Ask ChatGPT to draft an AI agent governance policy and it will produce something that reads like policy: sections, headers, a paragraph on 'responsible AI use.' It will not know that your Claude Code agents have standing write access to nineteen repositories, that three of those repos touch a Postgres instance holding customer PII, or that your SOC 2 auditor is going to ask for an access log that a generic policy document never generates. A generalist chatbot answers the question you typed. It has no visibility into your actual permission graph, no way to threat-model what an agent with your specific tool access could do wrong, and no mechanism for turning 'agents should follow least privilege' into an IAM policy that actually enforces it at runtime. The policy it hands back is a well-formatted Google Doc that no system checks against.
Cursor and GitHub Copilot solve an entirely different problem and were never asked to solve this one. They autocomplete inside a single file, tightly scoped to whatever the developer has open, optimized for finishing the next line fast. Neither tool has ever produced a written framework describing what an agent may touch across an organization, and neither has a way to answer if you asked. Governance is not a completion problem. It is a policy-authorship and enforcement problem: draft the acceptable-use rules, map them to actual permission boundaries, threat-model the gaps, and wire an audit trail that survives a compliance review. That needs an agent built for exactly that job, not one optimized for finishing your next function.
A written AI agent governance policy is not a Google Doc. It is a permission matrix an IAM system actually enforces, backed by a threat model that names what happens when an agent acts outside it.
Guard drafts the policy, Warden enforces the boundary
Tonone's Guard is the AI safety and guardrails agent: input and output filters, PII detection, content moderation, and runtime policy enforcement. For governance work specifically, Guard is the agent that turns 'we need an AI agent governance policy' into an actual document with teeth. It starts with reconnaissance, not drafting. The guard-recon skill maps the current state of AI safety controls across the org: which filters exist today, where the coverage gaps sit, what the incident history already shows about where things went wrong. You cannot write a policy against controls you have not inventoried, and most first-draft governance policies fail an audit precisely because nobody ran this step first.
Once the current-state map exists, guard-design produces the actual policy layers: input classifiers that flag what an agent is being asked to do, output validators that check what it is about to do before it does it, PII scrubbers for anything that touches customer data, and a policy rule engine that encodes what an agent may read, write, and execute. This is the acceptable-use framework, expressed as enforceable rules rather than prose a compliance officer files and forgets. After the framework ships, guard-audit closes the loop: it tests the written policy against bypass vectors and false-positive rates, red-teams the rule engine the way an attacker or a careless prompt would, and reports the policy gaps before an external auditor finds them for you.
Tonone's Guard drafts the acceptable-use framework defining what an AI agent may touch, not just what it should refuse to say.
Warden: permission boundaries and the threat model behind them
A policy that says agents should follow least privilege is a sentence. Tonone's Warden, the security engineer agent for IAM, secrets, threat modeling, and hardening, is what turns that sentence into an enforced boundary. The warden-iam skill builds the actual permission structure from scratch: roles, policies, and service accounts scoped per agent function, so a code-review agent gets a fundamentally different credential than a deploy agent, and neither gets anywhere near a standing production database connection. This is the piece most first-pass AI rollouts skip, because it is easier to hand every agent a broad service token and sort out the blast radius later. Warden's job is making sure there is no later.
Alongside the permission boundaries, warden-threat produces the threat model that the incident response plan actually needs: the assets an agent can reach, the ranked threats given its actual tool access, the mitigations already in place, and the risks the organization is knowingly accepting. This is the artifact that finally gives the incident response runbook its missing severity path. When an agent-caused incident happens, the on-call engineer is no longer improvising a response to a scenario nobody planned for; they are pulling up a threat model that already named this exact failure mode and assigned it a mitigation.
Where the policy intersects regulatory exposure, GDPR data residency for an agent that reads EU customer PII, SOC 2 evidence requirements for an access log that distinguishes agent actions from human ones, Tonone's Shield pulls in the regulatory read. The shield-assess skill produces a regulatory exposure assessment for the described product and its data flows, so the governance policy is not just something security signs off on, it is something the auditor accepts on first pass.
Tonone's Warden turns 'agents should follow least privilege' into an actual IAM policy: scoped service accounts instead of a sentence in a governance doc nobody enforces.
A worked example: Amberflow's first AI agent governance policy
Amberflow is a 38-engineer payments SaaS company, Series B, six months from a SOC 2 Type II renewal. Claude Code spread organically starting in Q1: the platform team adopted it first, results impressed the CEO in a demo, and by July it is running across six teams and nineteen repositories with no formal rollout plan behind it. Agents are wired into CI, one MCP connection reaches the staging Postgres instance, another reaches Stripe in test mode, and the security team, when asked directly, cannot say with confidence which agents can reach what. The SOC 2 auditor's kickoff call is in eleven weeks. The CISO wants a written AI agent governance policy on the board's desk before that call, not after it.
The work starts with guard-recon and warden-recon run in parallel against the actual environment, not a survey sent to engineering leads. The inventory turns up four agents with standing write access to the staging database that sits one config flag away from prod, two MCP servers pointed at Stripe with keys that were never rotated to test-only scope, and zero audit trail distinguishing an agent-authored commit from a human one, which means the existing SOC 2 evidence package has a hole in it nobody had flagged. From there, Guard drafts the acceptable-use framework and Warden turns it into an enforced permission matrix. An excerpt from the resulting policy:
Amberflow AI Agent Governance Policy v1, excerpt
AGENT ROLE PERMISSION MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Code-review agent (Claude Code, repo-scoped)
Read: full repo, PR diffs, CI logs
Write: PR comments, suggested-change commits (draft only)
Forbid: merge to main, prod credentials, customer data access
Token: session-scoped, revoked on PR close
CI/deploy agent (Claude Code, pipeline-scoped)
Read: build config, staging env vars
Write: staging deploy trigger, rollback trigger
Forbid: prod deploy trigger without a human approval gate
Token: 15-minute ephemeral, reissued per pipeline run
Data-support agent (Claude Code, read-only)
Read: anonymized support ticket export
Write: none
Forbid: raw customer PII, direct Postgres connection, Stripe live keys
Token: none issued, no standing credential exists
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Incident trigger: any agent action outside its row above routes
to #sec-incidents and pages the on-call security engineer within
5 minutes, the same SLA as a human-caused breach.The measurable outcome: standing production-adjacent access for agents drops from four service accounts to zero, replaced by ephemeral fifteen-minute tokens reissued per pipeline run. Every agent-authored commit is now tagged distinctly in the audit log, closing the SOC 2 evidence gap the recon step surfaced. The incident response runbook gains a fourth severity path, agent-caused, mapped directly to Warden's threat model, with its own five-minute paging SLA instead of getting triaged as a vague 'unexplained staging change.' The policy Guard and Warden produced together is not a document the CISO presents once. It is the permission matrix the IAM system enforces every time an agent opens a session, and the artifact the auditor reads in week one of the SOC 2 kickoff instead of asking Amberflow to reconstruct it live.
| Capability | Tonone | Generalist chatbot | Cursor / Copilot |
|---|---|---|---|
| Drafts an acceptable-use framework | Yes, Guard maps current controls then designs enforceable policy layers | No, produces generic policy prose with no link to your actual controls | No, autocomplete tool, not a policy-authoring agent |
| Defines agent permission boundaries | Yes, Warden builds least-privilege IAM roles and service accounts per agent role | No, no visibility into your permission graph | No, edits code, does not touch IAM |
| Threat models agent-caused incidents | Yes, warden-threat ranks threats and mitigations for the agent's actual tool access | No, cannot see what tools your agents actually hold | No, not a security or threat-modeling function |
| Regulatory exposure read (GDPR, SOC 2) | Yes, Shield's shield-assess reads data flows for regulatory exposure | No, no access to your data flow map | No, out of scope for an autocomplete tool |
| Red-teams the policy for bypass vectors | Yes, guard-audit tests coverage gaps and false-positive rates | No, cannot test a policy against your live controls | No, no policy to test against |
| Shadow AI inventory | Yes, guard-recon and warden-recon map what is actually running today | No, only sees what you paste into the chat | Limited, sees only the current file, not org-wide usage |
Run /guard-recon and /warden-recon this week, before you draft a single policy sentence. Most first-draft AI governance policies fail because they describe an ideal state instead of the agents, tokens, and MCP connections actually running today. Inventory first, then let Guard draft the framework and Warden turn it into enforced permission boundaries.
Install and try
Tonone is free and MIT-licensed. Install it once and Guard, Shield, and Warden are all available in your Claude Code session alongside the rest of the team. You pay only for the Claude Code token usage during the work itself.
1. Add to marketplace
2. Install Guard
Frequently asked questions
What is an AI agent governance policy?+
An AI agent governance policy is a written, enforced framework defining what AI agents in an organization are allowed to read, write, and execute, backed by permission boundaries an IAM system enforces and a threat model that feeds the incident response plan.
Which Tonone agent writes the AI agent governance policy?+
Tonone's Guard drafts the acceptable-use framework: it runs guard-recon to map current controls, guard-design to build the policy rule engine and PII scrubbers, and guard-audit to red-team the finished policy for gaps.
How do I set permission boundaries for AI agents like Claude Code?+
Tonone's Warden builds least-privilege IAM from scratch with the warden-iam skill: distinct roles and service accounts per agent function, replacing broad standing credentials with scoped, often ephemeral, tokens.
How do I find shadow AI usage nobody in security knows about?+
Run guard-recon and warden-recon together. They inventory the AI safety controls, IAM state, secrets, and MCP connections actually present in the environment, surfacing agents and access nobody formally provisioned.
Does my incident response plan need to cover AI agents?+
Yes. Tonone's Warden produces a threat model with warden-threat that names agent-specific failure modes and mitigations, giving the incident response runbook a dedicated severity path for agent-caused incidents instead of forcing on-call staff to improvise.
How does an AI agent governance policy relate to SOC 2 or GDPR?+
Tonone's Shield runs shield-assess to produce a regulatory exposure assessment covering the data flows an agent's access touches, so the governance policy holds up as SOC 2 or GDPR evidence rather than only satisfying an internal security review.
Is Tonone free to use for building an AI governance policy?+
Yes. Tonone is MIT-licensed and free. You pay only for Claude Code token usage during the work itself, and Guard, Shield, and Warden are all included.
How is this different from a generic responsible AI use policy template?+
A template describes intent in prose. Guard and Warden produce an enforced permission matrix, a red-teamed policy, and a threat model tied to the specific agents, tokens, and MCP connections actually running in your environment.