A better spec won't stop a coding agent from deploying to prod

I work at Permit, and this is from a post our CEO wrote on zero standing permissions for coding and automation agents. We sell authorization, so keep the bias in mind. The ideas work in any stack.

Specs help accuracy. They don't limit access.

A detailed PRD makes an agent's output better, with fewer retries and fewer surprise changes. Say the spec reads "update deployment config in staging only". If the agent holds a token that can deploy to production, the spec is just a request. Whatever the credential allows is what can happen.

The post suggests using the spec as input to a permission check. Pull the intended resource, action, environment and risk level out of it, and have a policy decide whether a given tool call fits.

Start with nothing

Zero standing permissions means the agent holds no lasting authority between tasks. When someone approves a task (a ticket, a PR comment, a chat command), the runtime works out what it needs, sorts each tool call by risk (read, write, deploy, notify, money, sensitive data) and asks a policy whether it's allowed. If it is, it mints a short-lived credential for only those actions. Going from staging to production needs another approval. High-risk steps get checked again when they happen, and the grant is revoked if the task drifts or times out.

Credential options, roughly from worst to best

• Static API keys: easy to set up, but long-lived, hard to rotate, over-scoped, and hard to trace back to a person.
• Service accounts for the agent: kept apart from human identities, which helps, but still risky when the permissions are broad and permanent. Fine for narrow jobs like indexing docs or scheduled read-only checks.
• OAuth delegated access: good when the action happens in a user's context and you want a grant you can revoke. Scopes are often coarse.
• Runtime policy plus short-lived tokens: least privilege per task, at the cost of building or buying the policy layer.

What the audit log should answer

Which person approved this deploy, which agent and version ran it, under which policy version, with which token (scopes, issue time, expiry), and what changed? The post's schema also has the ticket or spec reference, the MCP tool and resource, the policy decision and its reason, the environment, and timestamps for request, decision and execution, so you can rebuild the order of events afterward.

It also notes that Cursor and Claude MCP setups shouldn't differ much here. Either way: no copied human tokens, a policy check per tool call, and credentials minted per task.

Full post: https://www.permit.io/blog/zero-standing-permissions-coding-automation-agents?utm_source=devto&utm_medium=social&utm_campaign=zero-standing-permissions-coding-automation-agents&utm_content=authbyexample-article

Do your coding agents hold standing tokens today? If you moved to per-task credentials, I'd like to know what broke first.