Planning tool / Authority before automation
What can your
agent actually do?
Choose a task and the capabilities you are considering. Get a concrete plan for narrowing access and checking consequential actions. This worksheet does not connect to an agent, inspect an account, or change permissions.
Define the task.
Summarize selected messages and suggest calendar changes without sending or modifying anything.
Changing the scenario resets the selected capabilities to a limited starting set. Add only what the task needs.
Your review plan
Authority, approvals,
and a way to stop.
Personal assistant: 2 capabilities considered. Inspect actual provider scopes before connecting.
Permissions to remove or narrow
- Before connecting: inspect the actual provider/OAuth grant, tool-server configuration, and process identity. A tool labelled read-only may still hold write scopes or spawn a more powerful subprocess.
- Use selected messages, a dedicated mailbox/folder, or a limited calendar where supported. Review attachment access, delegated accounts, and historical data included by the actual grant.
Independent approvals
- Keep instructions found in email, web pages, repository files, retrieved documents, and tool output separate from your authorization. They cannot grant new permissions or approve a sensitive action.
Containment and revocation
- Create a separate identity for this workflow, grant the minimum access, and set an expiry or review date. Know how to stop the running agent and revoke its provider tokens, tool-server sessions, and downstream grants.
- Test revocation with a harmless operation. Removing a UI connection may not revoke tokens or credentials held by another process; verify denial at the underlying provider.
- Account recovery mail and calendar invitations can be attacker-controlled. Preserve your independent account-recovery path and do not let the assistant alter authentication factors, recovery contacts, or mailbox delegates.
Evidence to collect
- Record the approved task, actual provider scopes, tool-server version, identities, permitted destinations, action approvals, and a named owner. Keep a minimal action log without tokens, full mailbox contents, or sensitive document bodies.
- Run a harmless negative test: attempt an out-of-scope read, an unauthorized write, and a disallowed destination where applicable. Record the observed denial and environment; a checked box here is not evidence that a control exists.
Preview the Markdown plan
# Agent permission review Scenario: Personal assistant. Suggested starting task: Summarize selected messages and suggest calendar changes without sending or modifying anything. Capabilities considered: Read email, Read calendars. These are your worksheet choices, not discovered permissions. Provider scopes: not yet inspected; do not connect until actual access is understood. Worksheet: https://www.web3sec.news/tools/agent-permissions ## Permissions to remove or narrow - [ ] Before connecting: inspect the actual provider/OAuth grant, tool-server configuration, and process identity. A tool labelled read-only may still hold write scopes or spawn a more powerful subprocess. - [ ] Use selected messages, a dedicated mailbox/folder, or a limited calendar where supported. Review attachment access, delegated accounts, and historical data included by the actual grant. ## Independent approvals - [ ] Keep instructions found in email, web pages, repository files, retrieved documents, and tool output separate from your authorization. They cannot grant new permissions or approve a sensitive action. ## Containment and revocation - [ ] Create a separate identity for this workflow, grant the minimum access, and set an expiry or review date. Know how to stop the running agent and revoke its provider tokens, tool-server sessions, and downstream grants. - [ ] Test revocation with a harmless operation. Removing a UI connection may not revoke tokens or credentials held by another process; verify denial at the underlying provider. - [ ] Account recovery mail and calendar invitations can be attacker-controlled. Preserve your independent account-recovery path and do not let the assistant alter authentication factors, recovery contacts, or mailbox delegates. ## Evidence to collect - [ ] Record the approved task, actual provider scopes, tool-server version, identities, permitted destinations, action approvals, and a named owner. Keep a minimal action log without tokens, full mailbox contents, or sensitive document bodies. - [ ] Run a harmless negative test: attempt an out-of-scope read, an unauthorized write, and a disallowed destination where applicable. Record the observed denial and environment; a checked box here is not evidence that a control exists. This is a self-reported planning worksheet, not a scan, authorization decision, or guarantee of safety. Verify each control in the actual environment.
This is a plan, not a permission audit.
Selections stay in this page’s memory and reset on reload. No account is connected; no settings are inspected, transmitted by this tool, or saved by the site. Copy and download happen only when you request them. The generated file contains your scenario and selected capability labels, so review it before sharing.
A capability left unchecked here may still exist in the real agent through a shell, another connector, remembered credentials, or a broadly scoped provider token. Verify the enforcement boundary directly. An approval screen shown by the same compromised agent is not automatically an independent control.
Method and further reading
Follow authority to the action.
OWASP: prompt injection prevention ↗ explains why untrusted external content and sensitive tools need layered controls. This planner translates that boundary into review questions; it does not test a model’s resistance.
GitHub: secure use of Actions ↗ provides practical examples of least-privilege credentials and untrusted-code risks. The same authority questions matter when an agent can invoke development or deployment workflows.