Give your agent a supplementary card first: a permission contract for agent actions in vibe projects

Start with a scene: the agent means no harm, but it holds your keys

Picture your vibe project live, with an agent handling daily chores: every morning it summarises orders, clears expired data, and sends welcome emails to new users. One day you ask it to "clear the test data," and it does — except its idea of "test data" includes a batch of real seed users you imported last week. Nobody wrote the wrong code and nobody acted with malice. The problem sits one level lower: you never told this agent, in explicit terms, what it may touch, what it may not touch, whether it should ask you first, how much it may spend before stopping, or how its permission can be revoked instantly. You handed it a master key and hoped it would know which doors not to open.

That is the problem this guide solves: giving agents a permission contract. A contract is not a legal document but a set of rules that actually hold inside your project: every agent has a separate identity, every identity has an explicit permission scope, every permission has limits and approval tiers, every action leaves a traceable record, and every permission can be revoked with one click. If you have read this site's guides on agent spend hard caps, data-access guardrails, and human-approval workflows, the positioning of this piece needs stating first, because the four are easy to confuse. The hard-cap guide answers "how much spending triggers a stop"; the guardrails guide answers "which data the agent may see"; the approval guide answers "whether a given step needs a human nod." This guide answers a question that comes before all three: before any task starts, what is this agent allowed to do in the first place? In whose name does it act? Who granted its permission, when does it expire, and how is it taken back? The earlier three are brakes and fences during a task; this one is the issuing authority before the task begins.

An intuitive analogy comes from Walmart's Agent Profiles, announced on October 21, 2026: Walmart did not let shopping agents share a user's full account but gave each agent a dedicated profile, with limits, separate bookkeeping, and a switch-off at any time. This guide carries the same idea into your own project, except "shopping" becomes all of your project's external operations: sending email, calling APIs, changing databases, shipping releases, charging money, deleting data, and contacting customers. The point of the analogy is not Walmart but the order: issue credentials first, then do work.

The five parts of a contract: missing any one leaves a hole

A workable agent permission contract has five parts: identity, scope, limits and approval, records, and revocation. Without identity, you cannot tell whether the user or the agent did something. Without scope, the agent will cross lines you never thought of. Without limits and approval, small mistakes become large bills or irreversible losses. Without records, you cannot reconstruct what happened. Without revocation, discovering a problem leaves you watching it continue. The five parts must be written and implemented together; any one alone is incomplete.

First, identity: one separate identity per agent, never shared with a user account. An identity needs at least four items: the agent's name and purpose, which system or task it belongs to, where its credentials live, and who owns it. Credentials must be separated from user credentials: the API keys, database accounts, and third-party authorisations an agent uses should be created specifically for it, with minimum permissions — never your administrator key handed straight to it. Ownership matters just as much: every agent identity needs a real human owner, so when something goes wrong you know whom to ask first instead of asking a group chat "whose agent is this?"

Second, scope: define permissions with an allow-list, not a block-list. The problem with a block-list is that you can never finish listing what should not be done; the problem with an allow-list is that it takes time to think through what should be done — which is precisely the value of the contract. Scope must be written at the operation level, not the system level: not "may access the database" but "may read the orders table, may write to the logs table, may not modify the users table, may not run delete statements." For external services, scope goes to the interface level: may call the send-email interface, may not call the refund interface; may read the products interface, may not call the change-price interface. The more specific the scope, the easier it is to spot a crossing.

Third, limits and approval: sort operations into three tiers by reversibility and impact. Tier one is reversible and low-impact: reading data, sending internal notifications, generating drafts. These may run automatically, with records only. Tier two is reversible but costly or externally visible: emailing customers, calling paid APIs, changing public content. These need limit control and later review, or automatic execution within a limit with a stop and alert when the limit is exceeded. Tier three is irreversible or high-impact: deleting data, refunding, changing prices, shipping releases, contacting regulators, changing permissions themselves. These require per-transaction human approval, with no exceptions. Limits need two kinds at once: a per-action limit and a cumulative limit. The per-action limit stops a single runaway operation; the cumulative limit stops many small operations adding up to a large loss. The approval default must be "approval required": only operations explicitly listed in tier one may run automatically, and anything unlisted is by default not allowed.

Fourth, records: every agent action must leave four pieces of information: who did it, what was done, what data was used, and what the result was. Records must be stored separately from user-action records, at least filterable by agent identity. Retention periods must be set in advance: operations involving money, deletion, or permission changes should be kept at least long enough for a complete review; ordinary operation records may be shorter, but they must exist. Records are not for blaming a person; they exist so that when something goes wrong you can answer three questions: what did it do, why did it do it, and will it do it again? Without records, none of the three can be answered.

Fifth, revocation: revoking must be easier than granting. Revocation covers at least three actions: immediately invalidating the agent's credentials, terminating its running tasks, and notifying the owner and affected parties. The revoke button must not hide three menus deep, nor require a written application first. Regular review matters equally: every agent identity needs an expiry date, a reminder to the owner before expiry, and automatic expiry afterwards unless the owner actively renews. A permission with no expiry date sooner or later becomes an unclaimed master key.

A template you can copy directly

Below is a template you can drop into your project docs as a single page, to be filled in and confirmed by the owner before any new agent goes live. "Confirmation" needs no formal process, but it does need a real person's name: an agent with no owner is not allowed to launch.

Identity: agent name, one-sentence purpose, owning system or task, owner name, credential storage location, creation and expiry dates. Scope: data and interfaces it may read, data and interfaces it may write, an explicit list of prohibited operations, and permitted running windows (for example, business hours only, or release windows only). Limits and approval: per-action limit, daily and monthly cumulative limits, tier-one auto-execution list, tier-two within-limit list, tier-three must-be-human-approved list. Records: operation-log location, retention period, and how to filter by agent. Revocation: credential-invalidation steps, task-termination steps, notification list, and review cycle. Emergency channel: if the agent notices during execution that it may be crossing a line, it should stop first, preserve the scene, and notify the owner, rather than "finish first, explain later." The emergency channel is not a blank cheque for the agent; it is a brake: it has the right to stop, not the right to expand its own permissions.

Take a concrete example. Suppose your project has a "support-summary agent" that summarises the previous day's support conversations into a report each morning. Its contract should read: identity is the support-summary agent, owned by you; scope is read-only on the support-conversation and ticket tables, with no permission to change ticket status, message customers, or access the payments table; limits are at most one summary-API call per day, with results written only to the internal reports table; approval is automatic draft creation with owner confirmation before publishing; records are run time, number of tickets read, and the report link; revocation is a one-click disable in the admin panel, with credentials invalidated immediately. If one day you want it to also "escalate urgent tickets," that is not a one-sentence change but a fresh pass through the contract: escalating tickets is a tier-two or even tier-three operation, requiring new limits, a new approver, and a fresh assessment of whether it may touch the ticket-status field. Expanding permissions must go through process, not verbal agreement.

Take a counter-example. Suppose your project has an "auto-release agent" that pulls code, runs tests, and deploys to production. A contract reading simply "may deploy" is a blank cheque. The correct version reads: run only inside release windows, deploy only versions approved by a human, run a specified test suite before deploying, keep a rollback snapshot after deploying, stop and notify the owner on any test failure, and never deploy to production without an owner present. A release agent's permissions should not be as large as possible but as specific as possible: down to the version number, time window, test list, and rollback conditions, each written out so the agent has no room to improvise.

The five most common crossing patterns

First, credential reuse. One agent uses your administrator key, another reuses the same key, and in the end nobody can say who performed an operation. The fix is separate credentials per agent, minimum permissions only, regular rotation, and a rotation sequence of issuing the new credential first and then invalidating the old one, with a transition window in between.

Second, scope creep. An agent starts read-only, then someone casually lets it "also change this," then it starts deleting data. Scope creep is never one big jump but a series of "while you're at it" steps. The fix is that any scope expansion must refill the contract and be confirmed by the owner; verbal agreements do not count, and a "while you're at it" in chat does not count either.

Third, a total limit without a per-action limit. An agent with a $100 daily limit can still make a single $99 call that causes damage while staying "within limit." The fix is to set both: a per-action limit and a cumulative limit, with the per-action limit usually far smaller than the cumulative one.

Fourth, approval theatre. An approver receiving dozens of approval requests a day eventually clicks through without thinking. The fix is to reduce the number of operations needing human approval: pick out the genuinely high-risk operations for focused approval, and govern low-risk operations with limits and records instead of asking the approver to nod at everything. The fewer the approvals, the more each approval is worth.

Fifth, a revoke button nobody can find. Six months after launch, nobody remembers where an agent's credentials live or how to disable it. The fix is to write the revocation steps into the contract and to run a quarterly "revocation drill": pick an agent at random, walk through the invalidation flow for real, and confirm it actually stops. A revocation flow that has never been drilled is the same as having no revocation flow.

Three layers of enforcement: prompts do not count

Writing the contract in a document is not enough; it must actually block in technology. Use three enforcement layers. Layer one is the credential layer: the agent's key itself carries only minimum permissions, so when it tries to access the users table the database refuses directly, rather than relying on the agent to "behave." Implement this with separate database accounts and API keys per agent, granted strictly by the allow-list, so prohibited operations do not exist at the authorisation level. Layer two is the interface layer: external calls go through a gateway or proxy that enforces per-agent rate limits, limit accounting, and operation blocking — for example, the refund interface only accepts calls carrying a human-approval credential, and calls without one are stopped at the gateway before reaching business code. Layer three is prompts and task instructions: telling the agent what its contract is and to stop first when it may cross a line. The order of these layers cannot be reversed: prompts are the weakest layer and serve only as reminders, never as the sole defence. If you find a crossing that can only be prevented by "adding one more sentence to the prompt," the first two layers are missing; the real fix is to change credentials and the gateway, not the prompt.

The three layers also need a regular check: once a month, sample actual operation records and compare them item by item against the contract's allow-list. The focus is not whether the agent made a "big mistake" but whether it made "small crossings": did it read a table outside the contract? Did it run outside permitted hours? Did it call an unapproved interface? Small crossings are early signals of scope creep; the earlier they are found, the cheaper they are to fix. Record the check results as input to the next contract review: the contract is not a fixed file but a living document revised as the project grows. Every check, every incident, and every permission expansion is an occasion to revise it.

Where to start: three small things first, then the full contract

If a full contract feels too heavy, start with three small things, whose effect is already visible. First, give every existing agent a separate identity, split from user accounts, with credentials replaced by minimum-permission dedicated ones. Second, write a one-page scope statement per agent covering only the allow-list; operations you cannot write down are treated as not allowed. Third, give every agent an expiry date, with an owner reminder before expiry for review. Once these three are done, your project already has one more layer of protection than most vibe projects. Then gradually add limits, approval, records, and revocation drills, and the contract will naturally grow into its full form.

For a solo team there is one easily missed point: the owner is yourself, which does not mean the contract can be skipped. On the contrary, a solo team needs the contract more, because no colleague will catch a crossing for you. Writing it down leaves a checklist for your future self: three months later, when you return to this agent, you can immediately see what it may and may not do and when it expires. Without that checklist, you will sooner or later forget what permissions you granted, and forgotten permissions are the most dangerous ones.

Finally, a contract is not a file that is done once written. It must be revisited on every permission expansion, every incident review, and every owner change. In an incident review, besides asking "why did it do this wrong," also ask "did its contract cover this at all?" If the contract did not cover it, that is a contract gap; if the contract covered it but it still happened, that is an enforcement gap. The two gaps are fixed differently: the first by amending the contract, the second by technical constraints — for example, removing the disallowed operation at the credential level rather than merely writing "do not do this" in a prompt. Prompts are not permission control; credential-level and interface-level constraints are.

Closing: issue credentials first, then do work

The stronger an agent's capabilities, the more important its permission contract — not because agents are untrustworthy, but because the greater the capability, the greater the cost of misunderstanding. An agent without a contract is like an employee with no badge, no access list, but a master key: it may be very capable, but you never know which door it will open next. Give it a supplementary card, write down which doors it may enter, how much it may spend each time, which doors require asking you first, and how to take it back instantly. That is not distrust of the agent; it is the most basic responsibility to your project. Issue credentials first, then do work — a sentence worth putting at the top of every agent launch checklist.