Design input: OnPermissionRequest as a governance hook for production AI agents #6147
tamirdresher
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Context
PR #6146 adds a Squad + DTS incident-response sample to this repo. While writing it I kept returning to one design question worth a broader conversation: how should production agent systems gate tool execution at the agent boundary?
The two patterns in the samples today
What OnPermissionRequest enables
In the Squad model, an agent charter defines what it is allowed to do. When an action falls outside the charter, OnPermissionRequest fires before execution. The charter is operator-authored at deploy time, reusable across sessions, auditable (versioned document), and deny-by-default.
Design questions I would love input on
Should MAF expose a first-class IPermissionPolicy interface? Right now ToolApproval is a delegate on HarnessAgentOptions. An interface would let policies be injected, composed, and tested independently.
Charter persistence: config files, database, or a policy service like OPA? For multi-tenant deployments a per-tenant policy store feels necessary.
Permission taxonomy: should MAF define a standard taxonomy of permission categories, or leave it to each agent?
Cross-agent permissions: in the SquadWithDTS sample, a parent Squad delegates to subsystem Squads. Should the subsystem inherit the parent charter, or declare its own?
Emergency override: for incident response, sometimes you need to expand permissions mid-session. Should OnPermissionRequest support temporary scope elevation with auditing?
Related
Beta Was this translation helpful? Give feedback.
All reactions