Permission-Scoped Execution
Our execution architecture constrains agents and software to the systems, actions, and data they are explicitly permitted to access.
Reasoning is not authority
The ability to reason about an action is separate from the authority to perform it.
An agent may be able to identify that a customer record should change without having permission to modify the CRM. Another workflow may be allowed to update a narrow set of fields while remaining unable to delete records or access unrelated business units.
Permission dimensions
Execution can be scoped by system, action, data type, customer, business unit, and role. Conceptually:
- Proposed action
- Identity / role
- System permission
- Action permission
- Data + entity scope
- Allowed, denied, or approval required
This creates a control plane outside the model. The model can propose an action, select a tool, or prepare parameters. Deterministic authorization decides whether that action is within the permitted execution boundary.
Read and write boundaries
Permissions should distinguish between observing state and modifying it. Read access to customer history does not imply write access to customer status. Access to one business unit does not imply access to another. Permission to draft a communication does not imply permission to send it.
Narrow execution scopes reduce the consequence of both model error and software failure.
Runtime enforcement
Permission checks are most useful when enforced at the tool or API boundary rather than represented only as natural-language instructions.
A prompt that says “do not modify financial records” is weaker than a tool surface that simply does not expose a financial-write capability to that execution path. The same principle applies to customer, role, or business-unit restrictions.
Why this capability exists
Safe automation requires more than accurate reasoning. A system can produce an intelligent recommendation and still be unsafe if it has broader execution authority than the workload requires.
Give each workflow enough authority to complete its defined responsibility, and no more.
This allows increasingly capable automation without making every agent a general-purpose administrator of the company.
Permission context travels with execution
Permissions can affect more than whether a final write is allowed. They can constrain which records enter retrieval, which tools appear to the agent, which customer data enters context, and which actions can be proposed at all.
That matters in multi-step workflows. If an agent analyzes a record it was not permitted to access and the final write is later blocked, the permission system has still already failed at the read boundary. For that reason, access control belongs across the execution path rather than only at the final API call.
Permission state should also remain inspectable. When a workflow cannot continue because authority is insufficient, the system should be able to distinguish a permissions failure from a reasoning or tool failure so the exception is routed correctly.