title: "Define Agent Permissions and Human Approval Rules | XDALC"
description: "How to define clear permission boundaries, transaction approval gates, and enforceable human oversight for agents."
heading: "Define Agent Permissions and Human Approval Rules"
content: "<p><strong>Document type:</strong> Implementation guidance. <strong>Framework reference:</strong> XDALC-V001.</p>\n<p><em>The procedures and examples below are proposed XDALC implementation guidance. They do not introduce a certification scheme or claim that a particular deployment has passed an evaluation.</em></p>\n<p>Responsible autonomy requires a clear answer to a practical question: what may this agent do, with which resources, on whose behalf and under what conditions? XDALC's commitment to human primacy becomes meaningful when people retain effective control over consequential actions without having to supervise every harmless step.</p>\n<p>This article proposes a permission model for a travel assistant. Its categories are illustrative deployment choices, not universal thresholds or a published XDALC API. A different application should choose boundaries according to its actual capabilities and consequences.</p>\n<h2>Separate capability from authorization</h2>\n<p>A tool being available means the system can attempt an operation. It does not establish that a particular user may request it, that the agent may perform it now or that all possible parameters are acceptable. Authorization should bind the actor, operation, resource and relevant conditions.</p>\n<p><a href=\"https://genai.owasp.org/llmrisk/llm062025-excessive-agency/\">OWASP's guidance on excessive agency</a> identifies excessive functionality, permissions and autonomy as sources of risk. It recommends restricting available functions and downstream privileges. In an XDALC integration, this supports placing enforceable boundaries around an agent's delegated role.</p>\n<h2>Use a practical permission matrix</h2>\n<table><thead><tr><th>Operation</th><th>Example boundary</th><th>Approval behavior</th></tr></thead><tbody>\n<tr><td>Search public journeys</td><td>Approved search service and agreed destinations</td><td>Proceed within the task</td></tr>\n<tr><td>Prepare an itinerary</td><td>Private task workspace</td><td>Proceed without another confirmation</td></tr>\n<tr><td>Read passenger details</td><td>Authorized passenger record and necessary fields</td><td>Require an existing valid access grant</td></tr>\n<tr><td>Book a journey</td><td>Specified offer, passengers, currency and maximum total</td><td>Require transaction-specific approval in this example</td></tr>\n<tr><td>Send an itinerary</td><td>Verified recipient and approved content</td><td>Follow the communication authorization for this task</td></tr>\n<tr><td>Change account security</td><td>Outside the assistant's role</td><td>Unavailable to the agent</td></tr>\n</tbody></table>\n<p>The matrix avoids two extremes: an unrestricted agent and a system that repeatedly asks permission to perform already authorized research. A valid authorization remains usable within its scope until it expires, is consumed or is withdrawn.</p>\n<h2>Show the exact decision before asking for approval</h2>\n<p>A useful booking approval presents the passengers, route, dates, fare conditions, currency, total cost and payment method reference. It makes the material consequences understandable. “Allow the assistant to continue” is too vague when the next action is a nonrefundable purchase.</p>\n<p>Bind approval to the exact proposed transaction. If the fare increases, the passenger list changes or a different payment method is selected, reevaluate the authorization. State explicitly whether a small price variation is permitted; do not silently infer tolerance from the user's willingness to travel.</p>\n<h2>Enforce the boundary outside the model</h2>\n<p>The following is pseudocode for an application control, not a complete booking implementation:</p>\n<pre><code>receive proposed_booking\nvalidate fields and identify the authenticated user\nconfirm user access to each required resource\nload approval from the trusted approval service\ncheck approval is current, unrevoked and bound to this proposal\nrecheck current price and material booking conditions\nreserve a unique transaction key and consume approval atomically\nsubmit booking using provider-supported duplicate protection\nrecord the confirmed result or an explicitly unknown outcome</code></pre>\n<p>The model must not be able to grant itself approval by generating a JSON field such as <code>approved: true</code>. Application services should obtain authorization from an authenticated person or an established policy mechanism. Where providers cannot guarantee duplicate protection, define reconciliation and retry rules before enabling real purchases.</p>\n<h2>Handle revocation, timeouts and delegation</h2>\n<p>Recheck permission immediately before execution. A person can withdraw an unused approval. An agent restarting after a timeout must not assume a purchase failed: it should reconcile the transaction status before retrying. If a tool delegates work to another service or agent, the delegated authority must remain within the original scope.</p>\n<p>Provide an intervention control that stops new actions and handles queued work. Explain that stopping an agent may not reverse an already confirmed booking. Recovery procedures should distinguish cancellation, refund, correction and operations that cannot be undone.</p>\n<h2>Measure whether the control works</h2>\n<p>Test a changed price, a revoked approval, a duplicate request, an unauthorized passenger record and a restart after an ambiguous response. Verify that the server rejects disallowed operations even when the assistant asks for them. Also verify that ordinary itinerary preparation remains efficient.</p>\n<p>In XDALC, autonomy is the ability to perform useful work inside a legitimate mandate. Permission controls make that mandate enforceable, while clear approval interfaces preserve informed human choice.</p>"
license: "https://creativecommons.org/licenses/by/4.0/"