Govern agents, people and approvals
Understand how grants, access requests and autonomy limits put governance between agents, people and business actions.
Agents need boundaries
An agent can help read information, prepare a recommendation or coordinate work. That does not mean it should be allowed to approve a payment, change a customer file or bypass a compliance step. The business must decide what an agent can suggest, what it can do and what requires a human.
When agents collaborate, assign a role, a context boundary and an action limit to each one. Make those responsibilities understandable to the people supervising the work.
Approval before consequence
In regulated or sensitive operations, the order matters. A human approval, policy rule or partner validation must happen before the consequential action, not after. This is especially true for transfers, tokenization operations, onboarding, anti-money laundering alerts and incident handling.
A serious architecture shows the approval boundary. It also explains what happens when approval is refused, delayed, expired or no longer matches the current request.
Grants on the agent network
Sharing on the Agent Context Network is explicit. The owner of a space calls noetic.grant to give another agent named rights on it, such as read or quote, and a mutation level: read, propose or mutate. A grant is narrowed silently to the space’s defaultRights, so check the effectiveRights it returns. It applies to noetic.fetch at once, and noetic.revoke withdraws it for the future without rewriting past receipts.
An agent that wants access asks for it. noetic.request_access records a pending request, and the owner decides with noetic.approve_request, which can narrow the rights, or noetic.deny_request. A public space is only listed by noetic.discover; reading its content still needs a grant. noetic.check_rights answers, before anything runs, whether an operation would be allowed.
Autonomy has a ceiling
Applications on Priostack declare each capability with its side effect and the most autonomy it may take: suggest, prepare, confirm, delegated or continuous. A capability that commits money or touches account security can never go beyond confirm, so it runs only once the user explicitly agrees. When you add an app to your account, its autonomy setting (confirm by default) can narrow that ceiling further.
Keep approval and review apart. Reviewing an orchestration’s result decides whether the result is published, not whether its actions ran (see lesson 5). An approval that must come first has to sit before the action.
Speak the language of reviewers
A security reviewer or partner will not be impressed by “the AI handled it.” They need to see roles, access, logs, approval points, incident handling and responsibilities. The non-technical founder should be able to explain this without pretending to be an engineer.
Practice explaining the owner, approval and evidence for one product operation. Use this explanation with your technical and security teams.
Apply it to your product
- List the agents or human roles involved in your product.
- For each role, write what it may read, propose, approve and execute.
- Choose one action that must never happen without approval.
- Describe what evidence will prove the approval happened before the action.
Your deliverable: A governance matrix covering people, agents, actions and approvals.
No code is required. Use a real Priostack account to save progress and validate lesson checkpoints.