PATTERN Cited by 1 source
Session-scoped intent binding¶
Problem: If the declared intent for an AI agent session can be modified at runtime, a prompt injection or adversarial input could trick the agent into widening its own scope — defeating the purpose of intent-based authorization.
Pattern: Bind the intent to the session at creation time and make it immutable for the session's lifetime. The agent has no mechanism to modify, remove, or replace the bound intent.
Two binding modes¶
-
Design-time binding (autonomous agents): Intent is pinned in the agent's specification file. It never changes across sessions of the same type.
-
Session-start binding (interactive agents): The human describes the intent in plain language. The agent drafts a policy, the human approves it, and it locks for the remainder of the session. No mid-session changes without human re-approval.
Tamper-resistance properties¶
- No remove/edit tool. The agent is given tools for its job but no tool to remove, edit, or disable policies.
- Add-only with human gate. The agent may have a "browse policies" or "propose policy" capability, but activation requires human approval.
- Deny-wins composition (patterns/deny-wins-policy-composition) means even if a new permissive policy is somehow added, it cannot override the existing intent.
Seen in¶
- sources/2026-07-23-databricks-intent-based-authorization-omnigent — Omnigent binds intent per session; demonstrates that even direct requests from the agent to widen its own intent are refused because there's no lever to pull.
Related¶
- patterns/intent-based-authorization — the pattern this enables
- patterns/deny-wins-policy-composition — backstop if binding is bypassed
- concepts/intent-based-authorization — underlying principle
- systems/omnigent — reference implementation