AI agents · Permissions · Product architecture
How should an AI agent decide whether it can act?
Separate understanding a request, checking permission and executing an action. Make the action, destination and approval explicit before an agent changes anything.
Turn the request into a bounded action
An AI agent needs three distinct answers: what the person wants, whether the proposed action is allowed, and whether the connected system will accept it. Give each answer a clear place in the product.
Language interpretation should produce a specific proposed action. Identify the operation, the information involved, the destination and the person requesting it. A fluent response can still contain the wrong recipient or an incomplete understanding of the request.
For example, “send the latest numbers to the team” leaves important choices open. Which report? Which version? Which people? Convert that request into a concrete proposal before checking permission to send it.
Make uncertainty an explicit state
Use a permission check that can return allow, deny or hold. Hold means the action needs missing information or a decision from someone authorized to make it. Give the user a precise question that resolves the hold.
Bind approval to the proposed action. Approval to share one report with three colleagues should travel with that report and those recipients. If the content or audience changes materially, check again.
Keep a request identifier and the result of each check so the application can distinguish a retry from a new action. Extra checks add friction, so match them to the consequence of the action and the permissions already granted.
Enforce permission where the action happens
The system that sends, edits or deletes must enforce its own access rules. Recheck relevant permissions at execution time, because access and resource state can change after a proposal is prepared.
Evergences’ permission-check API pilot separates language interpretation from a structured rules layer and returns results with explicit hold states. That architecture gives developers a useful boundary: interpreting a request, evaluating it and executing it remain separate responsibilities.
Build that boundary into the first working workflow. It becomes harder to introduce once many tools depend on the agent’s interpretation.