A chatbot that answers questions and an agent that can execute payments do not represent two points on the same risk scale. The second can change the world outside its conversation. Once a system can modify records, issue refunds, invite users or send messages, the design question moves from fluency to authority. What may it do, on whose behalf, under which conditions and with what ability to reverse the action?
The principle of least privilege should apply to machine actors just as it does to people. Scope tokens to a tenant and a task, not to the entire platform. Use short-lived credentials, explicit tool allowlists, approval gates for irreversible actions, idempotency keys and an audit trail that links a decision to its input, policy and actor. An agent should not inherit broad permissions merely because the human who asked a question possesses them.
A second boundary is epistemic. An agent may act confidently on incomplete business context. The semantic layer defines what a metric means; the policy layer defines which action follows; evaluation measures whether those two remain aligned. If uncertainty is meaningful, a system should escalate rather than improvise. This is not a failure of intelligence; it is intelligent restraint.
Finally, make revocation a first-class capability. When a model, instruction or account becomes suspect, can operations be stopped immediately and past actions reconstructed? Governance is useful only if it works under pressure. The most advanced agent is not the one permitted to do everything, but the one trusted to do precisely what it should.
Design an authority envelope
Every agent needs a bounded mandate: purpose, tenant, resources, tools, spending threshold, allowed hours, expiry time and approval policy. A user request should not automatically elevate the agent to the user’s full privilege set. A successful authorization check should be about the requested action, not merely the identity of the caller.
What a consequential action needs
Before creating a payment or altering access, the workflow should establish context, verify a policy, present the exact proposed operation, record a stable idempotency key and enforce appropriate approval. After execution, preserve the result or compensating action with correlation identifiers. A natural-language explanation is useful, but it cannot replace the transaction log.
The limits of guardrails
Prompt instructions help but are not a security boundary. Tools must enforce their own authorization server-side. Model-produced arguments should be treated as untrusted input with validation, rate limits and business invariants. When the model is uncertain, the system should escalate without pretending a safe decision has already been made.
Operational drills
Test a revoked credential during a long-running task, a repeated callback, a failed third-party API, ambiguous recipients and a prompt injection embedded in a document. Track whether the system refuses unsafe operations and whether an operator can reconstruct the attempt. Governance becomes credible when these cases are rehearsed.