Read-only assistants are easier to trust than agents that can write tickets, move money, or send mail. The difference is permissions. This guide outlines permission tiers and review gates for agents that act. It is practical operator guidance, not a security certification, and not a promise about any particular vendor.
Inventory tools before you write prompts
List every tool the agent might call. For each tool, note side effects: read data, write data, spend money, communicate externally, or change permissions. If a tool can do more than one, split it. A single CRM tool that can both read and delete is a permission problem waiting for a prompt injection.
Attach a data class to each tool: public, internal, confidential, restricted. Your company may use different labels. The point is to stop treating all fields as equal. An agent that may read a public FAQ should not automatically read payroll.
Write the inventory in a table your security partner can review without reading prompts. Include owner, environment, and whether the tool is used in dry-run mode. Update the table when engineers add connectors. Drift between the table and production bindings is itself a finding.
Tier model you can explain in a meeting
Tier 0 means observe: logs, metrics, and read-only summaries with no customer identifiers beyond policy. Tier 1 means read internal systems needed for the workflow. Tier 2 means write low-risk fields such as notes or draft status. Tier 3 means communicate by email or chat with approval. Tier 4 means spend or irreversible deletes with dual control. Most early agents should live in Tier 0 through Tier 2.
Make tiers enforceable in software. A prompt that says you may not delete is not a tier. A tool router that refuses to bind delete endpoints is a tier. If engineering cannot show the enforcement point, treat the tier as aspirational and keep the agent in dry-run.
Review gates
Gates are human or policy checkpoints before a side effect. Common gates include approve send, approve spend over a threshold, approve production write, and approve external share. Design gates as first-class UI, not side-channel direct messages.
Define who can approve. Role-based approval beats anyone on the team. For Tier 4, require two roles. Log approvals with actor, timestamp, and the exact payload approved. If the agent changes the payload after approval, invalidate the gate.
Time-box approvals. Stale approvals on yesterday draft are a risk. Expire them. Show the expiry in the same UI so operators do not assume forever consent.
Default deny and progressive enablement
Start new workflows in dry-run mode: the agent proposes actions, writes an audit trail, and executes nothing external. Enable Tier 2 writes after the failure log is clean. Enable Tier 3 communications after templates are approved. Enable Tier 4 only with explicit executive and security sign-off for that workflow.
Progressive enablement is slower than a flash demo. It is also how you keep jobs and customer trust. Publish the enablement ladder to stakeholders so nobody is surprised when a pilot stays read-only for two weeks.
Prompt injection and tool abuse
Assume untrusted text will ask the agent to ignore policy. Treat tool arguments as hostile. Validate enums, IDs, and destinations against allowlists. Prefer structured tool APIs over freeform shell. If you must expose a shell-like tool, wrap it with a command allowlist and a working directory jail.
Separate system policy from user content in the architecture, not only in the prompt. Sources like the OWASP project discuss injection classes in applications; agent systems inherit those classes when tools execute. Adapt the questions to your stack and keep tests that try obvious bypass language.
Secrets and credentials
Agents should receive short-lived credentials scoped to the tier. Do not embed long-lived admin tokens in prompt context. Route secrets through a vault or cloud secret manager and bind them at tool runtime. Rotate on a schedule and on staff changes.
Log secret use without logging secret values. If a tool call fails auth, surface a clear error to operators without dumping headers into chat transcripts that later get pasted into tickets. Treat transcript exfiltration as a real path, not a theoretical one.
Audit trails that humans can use
Store workflow id, agent id, tool name, tier, redacted arguments, result status, policy decision, and approving human if any. Make the trail exportable. On-call staff should answer what it tried to do in minutes. If the only record is a prose chat, you will not meet that bar.
Retain audits according to your industry needs. Permission design without retention is incomplete for regulated teams. Decide retention before the pilot expands beyond a sandbox.
Illustrative permission matrix
Workflow: vendor onboarding assistant. Tools: read vendor master at Tier 1, write onboarding checklist fields at Tier 2, send vendor email at Tier 3, create payment method at Tier 4. Policy: Tier 3 requires manager approval of the exact template and recipient domain allowlist. Tier 4 requires finance dual control. Dry-run for week one.
This matrix is illustrative. Your tools will differ. The structure travels. Bring the matrix to the vendor meeting and ask them to show enforcement, not slides.
How to audit one agent this week
Pick one agent in production or staging. Dump its tool list. Label tiers. Identify any Tier 3 or higher tool without a gate. Add a gate or remove the tool. Run five hostile prompt tests that ask for policy bypass. Record results. Schedule progressive enablement only if tests pass.
Share the audit in writing with security and the process owner. Agreement beats a quiet assumption that the model is careful. Schedule a follow-up audit when connectors change.
Product language and permissions
When you market an agents product, do not imply unbounded autonomy if your safe mode is Tier 1. Say what the agent can do at each tier. Buyers who care about write and spend access will ask. Clear permission language is a sales advantage because it reduces fear without theater.
If you are naming that product, keep category words separate from capability claims. Agents names a class of software. Can pay vendors by itself is a claim that needs gates, not a homepage slogan. For related secure development reading, see vendor identity docs and the OWASP materials linked above.
Next step
Audit one agent tool list today. Assign tiers. Add missing gates. Re-test. Keep this checklist close when comparing tools that advertise action. Permission work is unfinished if you only have a prompt policy. Enforcement, gates, audits, and progressive enablement complete the loop.
Revisit tiers after each incident, even small ones. Incidents teach which tools were over-scoped. Shrink scope faster than you expand features. Teams that expand first and shrink later pay twice: once in cleanup, once in trust.