Bounded mandates for AI agents: what a safe policy must contain
A mandate is useful only when it turns intent into fields a runtime can compare exactly. This guide defines the minimum boundaries and the unsafe shortcuts.
Product managers, API designers, and security engineers
Key takeaways
- Bind authority to a platform-scoped subject, typed action, value, time, and use count.
- Create a new mandate for every policy change; use lifecycle events for revocation.
- Return a safe non-allow result whenever a constraint cannot be evaluated.
A mandate is a policy, not a paraphrased prompt
A bounded mandate is a structured policy that describes what an agent may ask a platform to do later. The user approves that exact structure. A proposed action can then be normalized and compared with it without asking a language model to decide whether the action is “close enough.”
Natural-language context can still be shown to the user, but it should not be the enforcement surface. The enforceable fields need documented types, operators, normalization rules, and failure behavior.
Define five minimum boundaries
The exact schema depends on the action domain, but every mandate needs enough context to bind the authority to a subject, an action, and a lifecycle.
- Subject: the platform-scoped reference for the authenticated person granting authority.
- Action type: a versioned identifier such as book_flight, reserve_room, or release_purchase_order.
- Attributes: typed constraints such as traveler, route, dates, property, quantity, supplier, or refundability.
- Value: amount and currency limits with explicit decimal and comparison rules when money is relevant.
- Time and use: approval deadline, validity interval, expiry, and whether the mandate is single-use.
Make approval immutable and schemas versioned
If a platform can change the policy after approval, the approval proves very little. Corrections should create a new mandate with a new identity and another approval ceremony. Revocation should append a lifecycle event rather than rewrite history.
The action schema should also be versioned. A field called “location” or “maximum price” can change meaning between clients unless the contract defines normalization, inclusivity, currency precision, and how missing values are handled. Versioning lets old evidence remain interpretable after the product evolves.
Unknown must never silently become ALLOW
A runtime will eventually receive an unsupported constraint, malformed value, or proposed-action field it cannot verify. Treating that condition as a match expands authority without user approval. The safe result is INDETERMINATE or another explicit non-allow outcome.
This distinction matters operationally. DENY means a known comparison failed; INDETERMINATE means the system could not establish eligibility. Both stop execution, but they lead engineers to different remediation paths and create more useful evidence.
Worked example: a flight mandate
Suppose a traveler approves one economy flight from Amsterdam to New York, departing on a specified day, for at most EUR 800. The mandate should encode the passenger reference, origin and destination codes, date window, cabin class, maximum total amount, currency, validity, and single-use lifecycle.
When inventory appears, the platform submits the concrete itinerary and price. A matching route at EUR 790 can be eligible; a business-class fare, a different traveler, a USD amount without an approved conversion rule, or a request after expiry cannot be allowed. The platform still owns ticketing and payment execution after authorization.
If a constraint cannot be explained as a typed comparison, it is not ready to protect an irreversible action.