Agent permission card

One card per shared agent: what it’s for, what it can reach and do, what needs approval, its limits and how to stop it.

Download

Blank template (.md)Fictional example (.md)

Principles involved

Overview

Every agent your team shares should have a card that anyone can read in a minute. If you can’t fill it in, the agent isn’t ready for real work.

Least privilege

Start with read-only or draft-only access. Add one permission at a time, when a real task needs it. Set limits in the system itself: a prompt is a request, and permissions are the lock. Avoid giving one agent private data, content from strangers and a way to send things out, all at once, unless your IT team has designed it that way on purpose.

The template

Each field says what to record. The fictional example shows what a finished record can look like.

Fictional example: the invoice-matching agent of the finance team at Lumen, an invented software company.

01Agent and purpose: Name the agent and the one job it does.

Fictional example

Invoice matcher: matches supplier invoices to purchase orders.
02Owner: Name the person responsible for the agent and its card.

Fictional example

The accounts payable lead.
03Can read: List the systems and data it can read.

Fictional example

The supplier invoices inbox (read-only), purchase orders and supplier master data.
04Can do on its own: List the actions it takes without approval.

Fictional example

Match invoices to orders and flag mismatches.
05Needs approval: List the actions that wait for a person.

Fictional example

Marking an invoice as approved for payment.
06Never: List the actions it must never take, enforced in its permissions.

Fictional example

Change supplier bank details, make payments or email suppliers.
07Limits: Set limits on money, recipients, volume and time.

Fictional example

Invoices up to €10,000. It stops after 200 invoices a day.
08Reads from outside: List the untrusted content it reads, such as emails or web pages, and how that’s handled.

Fictional example

Supplier emails and PDFs. Instructions inside them are ignored, and anything asking for a change is flagged for a person.
09How to stop it: Say who can pause it and how.

Fictional example

Any finance team lead, with the pause switch in the automation settings.
10How to undo its work: Say how to reverse what it did.

Fictional example

Matches can be reset from the audit log.
11Review date: Say when the card and its permissions are checked.

Fictional example

Quarterly, and whenever a permission changes.

Sources

What each source establishes, and its limits. The practices and recommendations on this page are ours, and the facts come from the sources. See every source we use.

OWASP Top 10 for LLM Applications, 2026 edition OWASP Gen AI Security Project · August 3, 2026 · Security guidance Lists the main security risks of AI applications, including prompt injection (LLM01), which it says can’t yet be reliably prevented, and excessive agency (LLM03): more functions, permissions or autonomy than a task needs. Recommends least privilege and human confirmation of privileged, irreversible or externally visible actions. Limits: Community guidance, not a formal standard.
Least privilege (glossary entry) NIST Computer Security Resource Center · Definition from NIST SP 800-53 Rev. 5 · Standard definition Defines least privilege as giving each entity the minimum system resources and authorizations it needs to perform its function. Limits: A glossary that compiles definitions from NIST publications.
Prompt injection is not SQL injection (it may be worse) UK National Cyber Security Centre · December 8, 2025 · Official guidance Explains that AI models have no reliable boundary between data and instructions, so prompt injection may never be fully fixed, and advises fixed, non-AI limits on what systems can do, least privilege and logging. Limits: Written for security professionals.
The lethal trifecta for AI agents Simon Willison · June 16, 2025 · Practitioner analysis Names the combination of access to private data, exposure to untrusted content and the ability to communicate externally as the condition for data theft through AI agents, and notes that no known technique reliably prevents it. Limits: A practitioner’s framework, not peer reviewed.
Model AI Governance Framework for Agentic AI Infocomm Media Development Authority, Singapore · Version 1.5, May 20, 2026 (first published January 22, 2026) · Voluntary framework Keeps organizations and their human supervisors accountable for agents’ actions; asks for human approval at significant checkpoints such as deleting data, sending messages and payments; treats very low override rates and very fast reviews as possible signs of rubber-stamping; prefers approvals enforced by system controls over prompts. Limits: Voluntary guidance, not law. Its case studies were supplied by the companies themselves.