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

Permit's CEO published a post arguing that detailed specs and PRDs cannot constrain coding agents, because an agent holding a production-deploy token will act on whatever the credential permits regardless of what the spec says. The post proposes treating the spec as input to a permission check and adopting "zero standing permissions": agents hold no lasting authority, each tool call is risk-ranked and policy-checked, and short-lived credentials are minted per task, with a fresh approval required to move from staging to production. It also outlines an audit schema capturing approver, agent and version, policy version, token scopes and expiry, MCP tool and resource, and request/decision/execution timestamps.

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. 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. 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. 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. Do your coding agents hold standing tokens today? If you moved to per-task credentials, I'd like to know what broke first.