# Policy recommendations for common agent archetypes What should your agent be allowed to do, what should pause for a human, and what should never run — split by attended vs. unattended, for the six shapes of agent almost everyone runs. Most policy questions about an agent reduce to one question: what should this thing be allowed to do while nobody is watching? The answer depends less on the model than on the job. Across the agents we run and the agents that run through our gateway, the same few shapes keep showing up — a copilot at your elbow, a worker running unattended, a scout that mostly reads, an agent that ships to prod. Each shape has a sane default policy, and the defaults are different enough that "one policy for all agents" is usually the wrong amount of control everywhere at once. Here is what we'd recommend for each, in three verdicts: what runs freely, what stops and asks a human, and what never runs. Where attended and unattended differ, we say so — that split matters more than any other. A rule that only holds while you're watching isn't a rule; it's supervision. ## The coding copilot Interactive, in your terminal, you at the keyboard. **Allow** the work: reads, edits, builds, tests, the ordinary shell. Approval fatigue is the failure mode to design against — a copilot that asks about everything trains you to say yes to everything, and then the asks protect nothing. **Pause** for the irreversible: file deletes, reads of `.env` and credential files. Keep the list short so each pause means something, and let a yes hold for a few minutes — approving the same delete three times in a row is how fatigue starts. **Deny** the one thing no human catches at conversational speed: a single command that reads a secret and sends it out. That check has to look at the real command text, per call, because the read and the send arrive together. Attended and unattended are the same here, deliberately: when a copilot spawns subagents, the subagents should inherit the fences, not the trust. ## The unattended worker Always-on, doing a job — triage, sync, drafting, monitoring. **Allow** the job: reads, writes, web, connector calls. Rate-limited, because a loop with no human in it has no natural stopping point. **Pause** nothing, ideally. Nobody is there to answer. An unattended pause is either a stuck agent or an auto-timeout, and both are worse than a clean allow-or-deny. Design the policy so every call resolves without a human. **Deny** the self-modification set: rewriting its own memory, touching the shell, scheduling itself, delegating to other agents, changing its own skills, reading credentials. An unattended agent that can edit its own memory or its own schedule is an agent whose next-week behavior you didn't write. This shape is not hypothetical. One production workspace denies its always-on agent's memory writes hundreds of times a week — and the agent keeps doing its job. The denials aren't friction; they're the fence holding, in writing. ## The research scout Gathers, summarizes, reports. **Allow** reads, search, and fetch — reading the world is the job — plus writes inside its own workspace, and read-shaped shell commands (`cat`, `grep`, `ls`). **Pause** any write outside the workspace, and any shell beyond reads. `curl` belongs on the pause list even though it looks like reading: it can POST data out. **Deny** credential edits, remote shells, and secrets in outbound requests. A scout has no reason to do any of these, so the deny costs nothing. A scout's policy barely changes unattended, which is what makes it the easiest agent to hand off first. ## The ops/deploy agent Touches infrastructure. **Allow** inspection: logs, status, describes, diffs. **Pause** every mutation — deploy, infra change, service control, deletes — *attended included*. This is the one archetype where pausing the attended path is the point: the approval is the deploy review. If that feels heavy, the agent you're describing isn't an ops agent yet. **Deny** is the honest gap here. What you actually want to deny is "anything aimed at prod," and a static rule can't reliably see "prod" inside a command's arguments. That class needs per-call inspection of the command itself. Until you have that, the pause-everything-mutating posture is the defensible one. ## The flight recorder A posture, not an agent: allow everything, block nothing, record every call, redact PII from the trail. This is the right day-zero policy for any agent that already exists and works. You get the answer to "what did it actually do?" before you decide what it may do — and most people who look at a week of the recording find their first deny rule in it. It's also a legitimate permanent choice for low-blast-radius agents where the trail is the requirement. The two longest-retained workspaces on our platform run the opposite extremes: one records everything and enforces nothing; the other fences everything unattended. Both work, because both are deliberate. The pattern that fails is the middle arrived at by accident — some checks, written once, holding for nobody. ## The scheduled/cron agent An unattended worker plus a trigger — and the trigger is the thing it must not own. Everything from the unattended worker applies. Add two rules: it must never create or edit its own schedule (an agent that schedules itself never stops), and it gets a per-run budget cap, because the 3 a.m. run has no one watching the meter. If the job writes anywhere that matters, start it draft-only and promote the writes after you've read a week of drafts. ## How to pick without guessing You don't have to reason your way to the right policy from this post. Run the candidate policy in shadow against your own agent's recorded calls: replay the last week, read every call it would have denied or paused, and check the list against what you know the agent should have been doing. If the would-have-denied list is all fence-probing, enforce it. If it's full of the agent's actual job, the policy is wrong, and you found out for free. We ship five of the shapes above as one-click personas that work exactly this way — shadow first, replay over your own last week, a diff before enforce ever acts. They're at [/personas](/personas). But the method stands on its own, whatever you enforce with: write the rule down, replay it against reality, and only then let it act.