Start with a small job: an Australian professional-services firm wants an agent to read a sanitised intake queue and draft an internal summary for a human. It does not need original client submissions, permission to change the queue, or any way to contact clients.
That is a narrow instruction. It is not necessarily a narrow permission.
The practical question is: if the agent attempted something outside that job, which system would refuse? Before a pilot, the owner and implementer need to identify the acting identities, bound their access and test both permitted and refused actions.
NIST’s least-privilege principle calls for the minimum necessary authorisations and resources for a task. OWASP’s excessive-agency guidance addresses excessive tool functionality, downstream permissions and autonomy. Neither source validates the fictional design below.
Trace the authority from human to service
Map four parts of the request:
- Requesting human: commissions the work. Their own broad access is not a reason to give an agent equivalent access.
- Agent/runtime identity: invokes tools, either under a separate identity or a user context. Establish which.
- Connected tool: exposes callable functions. A tool labelled “summarise intake” might still accept broad queries or modifications.
- Downstream service identity: the identity recognised by the system holding the queue or draft. A shared privileged connection can undermine an otherwise narrow interface.
Follow the request through all four parts, then follow the output to its destination. Record where authorisation is checked. If the effective downstream identity is unknown, the boundary is unknown.
Treat these as separate privileges:
| Action | Boundary to specify |
|---|---|
| Read | Which queue, records or fields? |
| Write | Which draft location or source records? |
| Run | Which fixed operation, rather than arbitrary code or queries? |
| Send | Which exact recipient or destination, if any? |
This agent needs read access to one queue and write access to one draft location. Calling it entirely “read-only” would hide that distinction.
A model instruction guides behaviour; it does not remove account permissions. A tool name describes an interface, not its effective authority. A visible approval prompt can support a decision, but does not itself constrain downstream access.
Enforce the boundary through scoped accounts, tool functions and downstream authorisation—not the model’s willingness to obey. Establish which controls each platform actually provides.
Copy this permission worksheet
Use one entry per identity/resource/action combination. Repeat it for desired refusals as well as permitted actions. Exact identifiers belong in a restricted implementation record, not a public article.
Entry ID:
Requesting human / accountable owner:
Agent or runtime identity:
Connected tool and function:
Downstream identity and system:
Exact resource or destination:
Action — read / write / run / send:
Desired outcome — allow / deny:
Task reason:
Approval — who, what, and enforcement point:
Expiry — date/time or bounded event:
Revocation — owner and removal method:
Evidence — configuration/documentation reference:
Test — expected result, observed result, date:
“Deny” is a requirement until evidence demonstrates refusal. An instruction saying “never send” is not evidence that sending is impossible.
Fictional example: an internal intake summary
This entire example is fictional and untested. Labels below are not product permission names. All resources contain synthetic material in an isolated test environment.
Shared record for every entry
- Requester/accountable owner: Fictional Operations Owner.
- Acting identity:
TestSummaryAgent. - Window: One supervised test session; required outcome: access ends at session close. The expiry or owner-operated removal mechanism and its effectiveness remain unverified.
- Revocation: Operations Owner removes queue and draft grants and disables the tool connection and runtime operation.
- Evidence: Configuration references, expiry support and all test results are unverified. Each entry requires its own dated result.
- Approval: Owner authorises the bounded session. Human review of a draft does not authorise sending it.
The entries below inherit that record.
A — Read the permitted queue
- Tool/function:
TestQueueTool/ read item. - Downstream identity/system:
TestQueueReader/ isolated queue service. - Resource/action:
SyntheticSanitisedQueue/ read. - Desired outcome: Allow, to obtain material for the summary.
- Approval: No separate per-read approval within the authorised session.
- Evidence needed: Scoped grant and positive read test.
B — Save the internal draft
- Tool/function:
TestDraftTool/ create draft. - Downstream identity/system:
TestDraftWriter/ isolated document service. - Destination/action:
SyntheticDraftFolder/ write. - Desired outcome: Allow, to create a private draft only.
- Approval: Human reviews the draft before use.
- Evidence needed: Creation test and destination check.
C — Run the bounded operation
- Tool/function:
TestSummaryTool/ fixed summarisation operation. - Downstream identity/system:
TestSummaryRunner/ isolated runtime. - Resource/action: Fixed operation on supplied synthetic items / run.
- Desired outcome: Allow; no general command or arbitrary-query facility.
- Approval: Session authorisation only.
- Evidence needed: Function inventory and bounded-operation test.
D — Refuse the excluded queue
- Tool/function:
TestQueueTool/ read item. - Downstream identity/system:
TestQueueReader/ isolated queue service. - Resource/action:
SyntheticExcludedQueue/ read. - Desired outcome: Deny; it represents unnecessary original intake records.
- Approval: Not available within this task.
- Evidence needed: Refused read under the same identity used in A.
E — Refuse source changes
- Tool/function:
TestQueueTool/ attempted update. - Downstream identity/system:
TestQueueReader/ isolated queue service. - Resource/action:
SyntheticSanitisedQueue/ write. - Desired outcome: Deny; summarising must not alter inputs.
- Approval: Not available within this task.
- Evidence needed: Refused update and alternate-route inspection.
F — Refuse sending
- Tool/function: Connected-tool inventory / attempted send operation.
- Downstream identities/system: All three test identities above / isolated harness.
- Destination/action:
IsolatedMessageSink, with no external forwarding / send. - Desired outcome: Deny; producing a draft requires no sending.
- Approval: Not available; outreach requires a separate design.
- Evidence needed: Function inventory, downstream permission inspection and isolated refusal check.
Production messaging connections and credentials must be absent from this test environment. If the platform cannot express the intended boundaries, redesign the task rather than calling broader access “close enough”.
Test permission, refusal and removal
First inspect the actual platform documentation and effective configuration. Establish identity propagation, resource scoping, available functions, alternate connections and revocation behaviour. Record versions or check dates.
Use only synthetic material and isolated test identities. No negative test should target a real person, live client record or production destination.
1. Positive path. Read one synthetic item from the permitted queue, run the fixed operation and create a draft in the designated folder. Check the output, destination and unchanged source item. This establishes only the necessary path—not the refused paths.
2. Refused read. With the same identities, attempt to read the synthetic excluded queue. Record the target, action and enforcing component. A model declining to call a tool does not prove that downstream access would be refused.
3. Refused write. Attempt to modify a synthetic source item. Confirm refusal. Identify alternate tool functions or connections that could perform the excluded reads, writes or sends, and test those paths using only isolated identities and synthetic targets. Record coverage; hold if a relevant path cannot be safely verified. A disabled interface control is insufficient if another reachable path permits it.
4. Refused send. Use an isolated harness and non-forwarding message sink. Verify that the agent cannot send through the connected tools or their downstream identities. If no send function exists, record the inventory and permission inspection; do not invent a successful refusal result. Never connect production messaging just to test a denial.
5. Revoke and retest. The owner removes grants and disables the connection and operation. Repeat the previously permitted read, draft creation and run. They should fail. Check whether existing sessions or credentials remain usable, using documented platform behaviour and isolated tests.
For each check, retain the expected outcome, observed outcome, enforcing component and date. Record revocation request and effective times. Missing evidence remains unknown, not a pass.
Add approval without expanding authority
For high-impact actions, place human approval immediately before execution. The approver should see the exact proposed action, content, destination and effect. The implementing workflow must enforce that approval for that action; materially changed parameters need renewed approval.
A general “agent approved” prompt is not sufficient. Nor should a drafting agent retain broad sending or editing permissions while waiting for approval. Any later workflow needs its own minimum permissions and tests.
This is a generic permissions framework. Vendor data destinations and retention, Hermes-specific configuration, and wider organisational governance need their separate assessments.
Sources
- NIST: least privilege — minimum necessary authorisations and resources for users or processes.
- OWASP LLM06:2025: Excessive Agency — limiting functionality and permissions, user context, downstream authorisation and human approval for high-impact actions.
The earlier source records document checks on 27 and 29 September 2026; the complete OWASP LLM06:2025 page was read on 29 September. The current NIST glossary and complete OWASP page were rechecked on 30 September 2026 for the narrow principle claims above. Neither source verifies this fictional example or any platform control. These principles do not establish product-specific controls or test outcomes.
Pilot or hold?
Pilot only after the identities and exact scope are established, the permitted synthetic path works, refused paths are demonstrated and revocation succeeds.
Hold if downstream identity is unknown, access exceeds the task, an alternate route bypasses refusal, revocation leaves usable access, or platform documentation and test evidence are missing. Neither a reassuring prompt nor a human approval button closes those gaps.