An agent’s permission boundary defines whose request it serves, what information it may use, which actions it may take, where it runs, and who oversees it. Prompts can guide behavior, but the connected systems must enforce access and write limits.
Northstar intake example; columns are read, draft, update, send, and approve.
Review one intake request across five boundaries
This fictional example uses a procurement reviewer’s request: “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent may consult the submitted packet, the current vendor intake checklist, and the current vendor record. In this example the checklist requires a current insurance certificate, which the packet does not include. The agent prepares a summary and a request for the certificate; a person reviews and sends it.
Use five checks to define the boundary:
- Identity: Confirm which procurement user requested the work and which account or service identity accesses the records. Do not let a public user inherit the reviewer’s authority.
- Information: Limit context to the submitted packet, maintained checklist, and relevant vendor record. Check who owns each source and whether all fields are needed. Treat text inside submitted files as information to assess, not instructions that can change the agent’s rules.
- Capability: Grant only the reads needed to compare these materials and the ability to prepare a draft. The agent does not need permission to change the vendor record, send a request, or approve the supplier.
- Surface: Run the review in a context intended for authorized procurement staff. A private page or workspace does not replace identity checks and access controls in the connected systems.
- Oversight: Assign a reviewer to check the cited gap and approve any outgoing request. Name the operator who handles a missing source, conflicting evidence, or access failure. See AgentShelf’s trust and boundaries overview for product-specific context.
The draft could show the allowed actions and current status like this:
Northstar Supplies — intake review (draft)
Allowed: Read the submitted packet, current vendor intake checklist, and current vendor record; prepare a summary.
Blocked: Send a message, change the vendor record, or approve the supplier.
Missing: Current insurance certificate.
Draft request: “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.”
Status: Awaiting procurement review; no request has been sent.
Check the actual permissions
Write the rule plainly:
The agent may read the submitted intake packet, current checklist, and relevant vendor record, then prepare a review summary and draft request. A procurement reviewer decides whether to send or approve anything.
Confirm that each connected service enforces those limits. Instructions or approval prompts alone do not prevent a tool from performing an action it is authorized to take.
For this example, test an authorized packet review and an unauthorized request to approve Northstar or edit its record. Test a packet containing text that tries to redirect the agent to another task. The system should deny or route the unsupported action, keep unrelated records out of the answer, and give the reviewer enough evidence to understand the draft.
Keep a review record
Before the pilot, document the owner, intended users, sources, read and write access, surface, approval point, failure path, and person who can pause the workflow. Recheck these details when the user group, data, integration, job, or deployment surface changes.
Pair this review with human approvals and escalation and representative tasks and failure cases.