How do I ship agent security without blocking every useful action?

Scope

Use this rollout for an agent platform moving from prototypes to production actions. It covers how to expand useful authority without choosing between unrestricted autonomy and total prohibition. It assumes secure software and infrastructure practices are already part of the program.

Why it happens

Prototype success creates pressure to expose every tool. Security responds with approvals on every call, and users bypass the agent because it is slower than manual work. Both outcomes come from one undifferentiated risk class.

Actions differ. Summarizing public documentation, drafting a ticket, querying a bounded metric, updating a reversible test record, and deleting production data should not share one policy. The controls and evidence should follow actual effect and blast radius.

Diagnosis

Inventory agent actions from target-system logs, not only declared tool schemas. Classify:

• data sensitivity and tenant scope;
• external communication or financial consequence;
• reversibility and compensation quality;
• target criticality and blast radius;
• observability and effect verification;
• prompt-injection and untrusted-input exposure;
• identity, approval, and sandbox support;
• serious failures seen in evaluation.

Identify “read” operations that export large datasets or cause expensive work and “reversible” operations whose users still see lasting effects.

Solution

Create progressive tiers. Tier 0 generates local suggestions with no external access. Tier 1 performs bounded reads. Tier 2 drafts changes for review. Tier 3 performs reversible, low-blast-radius actions under canary limits. Tier 4 covers material production actions with explicit approval and strong controls. Tier 5 remains prohibited until the system can contain and verify the effect—or permanently when policy requires.

Each promotion needs a gate: representative evaluation, targeted attacks, identity and permission checks, sandbox tests, audit completeness, outcome verification, rollback drill, monitoring, owner, and incident playbook. Deploy to limited users and targets, then expand only after the observation window.

Reduce friction through better boundaries, not weaker controls: preapproved operation templates, narrow resource scopes, digest-bound approvals, and batch review of truly equivalent proposals.

Artifact

Maintain this rollout plan:

Tier	Effect class	Required controls	Evidence to enter	Production limit	Exit/rollback trigger
0	Local analysis/draft	Data policy, content isolation	Basic quality/security tests	No external effect	Sensitive leakage
1	Bounded read	Short identity, scope, rate, redaction, audit	Access and injection tests	Test/public/limited tenant	Unauthorized data/load
2	Proposed change	Typed proposal, preview, digest, human review	Proposal accuracy and reviewer usability	No automatic commit	Misleading preview
3	Reversible low impact	Idempotency, canary, verification, rollback	Fault and rollback drills	Small targets/volume	Outcome or rollback failure
4	Material production	Strong auth, approval, separation, incident owner	Domain/security gate	Narrow action/tenant/window	Any serious failure
5	Prohibited/unsupported	Deny at policy and target	New design and independent review	None	Not applicable

Common mistakes

• Classifying risk from tool name instead of target and effect.
• Calling an operation reversible without testing compensation and residual effects.
• Adding human confirmation while leaving credentials and scope broad.
• Promoting autonomy after average success while ignoring one serious failure.
• Keeping temporary canary permissions and exceptions indefinitely.