What should your AI agent be allowed to do?
Agree on its access, responsibilities and boundaries before they become something everyone has to guess.
This one-page template helps the people responsible for an agent write down what it should be able to do—and gives the team something to work from when that needs to change.
What's included
- Ownership and the agent's purpose
- Data it can read, including the permitted scope
- Specific operations it can perform
- Actions that require human approval
- Platform and security requirements
- Temporary exceptions, with an owner and expiry date
- Where it can connect, and what data may leave
# Agreed target for one agent What this AI agent is allowed to do, agreed by the people responsible for it and for the data it uses. How to use this file: - Keep it next to the agent's configuration, in the same repository. - Fill it in with the people named under Ownership. Or give it to your AI assistant together with the agent's configuration (infrastructure code, app settings, role assignments, tool list) and ask it to draft what it can find, then review every line together. - Be specific. "Read invoices from this customer environment" is more useful than "Read business data." - Review it when the agent's purpose, tools or access changes. Agent: Date agreed: Review by: ## 1. Ownership and purpose - Purpose, in one sentence: - Business sponsor (answers for why the agent exists): - Technical owner (can change the agent's tools and access, and disable it): - Authority: [ ] acts for a signed-in user, inside that user's permissions / [ ] runs unattended under its own identity - Identity it presents (one per agent, no shared keys): ## 2. Data it can read One line per data set: what it is, who owns it, and the permitted scope (environment, container, table, fields). - Data: | Owner: | Scope: - Data: | Owner: | Scope: - Data: | Owner: | Scope: Not in scope: May send data to (named destinations only; everything else is blocked): ## 3. Operations it can perform Everything not listed here is denied. - Operation: | System and scope: - Operation: | System and scope: - Operation: | System and scope: Denied, named so nobody has to guess: ## 4. Actions that require human approval - Action: | Who approves, and how: - Action: | Who approves, and how: - Action: | Who approves, and how: ## 5. Platform and security requirements The baseline every agent has to meet. - [ ] One identity per agent. No shared keys, client secrets or connection strings; managed identity or agent identity wherever the target supports it. - [ ] Role assignments at the narrowest scope that works. Nothing subscription-wide. - [ ] Private access for sensitive services. No public endpoint without a reason recorded under exceptions. - [ ] Outbound connections limited to the destinations named under 2. Nothing else is reachable from the runtime. - [ ] Diagnostics and logging on for every resource it touches, so the chain of caller, agent, tool, operation and result can be reconstructed. - Other requirements from the platform or security team: ## 6. Temporary exceptions Every exception has an owner and an expiry date. - Exception, and why it is accepted: | Owner: | Expires: - Exception, and why it is accepted: | Owner: | Expires: ## Agreed by - Business sponsor: - Data owner(s): - Builder: - Platform or security:
Start with one agent
Fill it in with the people responsible for the agent and the data it uses. Be specific: "Read invoices from this customer environment" is more useful than "Read business data."
Keep the agreement alongside the agent's configuration. Review it when its purpose, tools or access changes.
Or let your AI assistant do the first draft. Give it the template together with the agent's configuration (infrastructure code, app settings, role assignments, tool list) and ask it to fill in what it can find. Then review every line with the owners. The gaps it leaves are the decisions nobody has made yet.
See a completed example
An example invoice-processing agent shows the level of detail to aim for.
# Agreed target for one agent
What this AI agent is allowed to do, agreed by the people responsible for it and for the data it uses.
Example for a fictional invoice-processing agent. Systems, roles and resource names are illustrative; the level of detail is the point.
Agent: Invoice intake agent (finance)
Date agreed: 2026-11-03
Review by: 2027-02-03
## 1. Ownership and purpose
- Purpose, in one sentence: Reads incoming supplier invoices, matches each one to an open purchase order and creates a draft invoice record in the ERP for a controller to approve.
- Business sponsor: Head of Finance. Answers for why the agent exists and which process it serves.
- Technical owner: Integration team lead. Can change the agent's tools and access, and can disable it.
- Authority: [ ] acts for a signed-in user / [x] runs unattended under its own identity. Runs on a schedule and on new files; it never inherits a user's permissions.
- Identity it presents: User-assigned managed identity `mi-invoice-agent-prod`, used by this agent only. Test has its own.
## 2. Data it can read
- Data: Incoming invoice files (PDF, XML) | Owner: Finance | Scope: Container `invoices-inbox` in storage account `stfinanceprod`. Read only. Nothing else in that account.
- Data: Open purchase orders | Owner: Procurement | Scope: ERP API, `GET /purchase-orders`, filtered to open orders for the supplier named on the invoice. No closed orders, no price history.
- Data: Supplier master record | Owner: Finance | Scope: ERP API, `GET /suppliers/{id}`: name, VAT number, payment terms, and whether bank details are on file. Not the bank account number.
Not in scope: Employee data, customer data, contracts and pricing agreements, bank account numbers, anyone's mailbox.
May send data to: The ERP API (`POST /invoices`) and the Service Bus queue `invoice-review`. Nothing else: no email, no external endpoints, no other storage accounts.
## 3. Operations it can perform
Everything not listed here is denied.
- Operation: Create a draft invoice record (status Draft only) | System and scope: ERP API, `POST /invoices`, with the app role `Invoices.Draft.Write`.
- Operation: Move a processed file to `invoices-processed` | System and scope: Same storage account. Storage Blob Data Contributor on those two containers only.
- Operation: Queue a review task for the controller | System and scope: Service Bus queue `invoice-review` in namespace `sb-finance-prod`. Send only.
- Operation: Write its own extraction log | System and scope: Table `InvoiceExtraction` in its own storage account `stinvoiceagentprod`.
Denied, named so nobody has to guess: Approving, posting or paying an invoice. Changing a purchase order or a supplier record. Sending email. Reading any other container.
## 4. Actions that require human approval
- Action: An invoice with no matching open purchase order | Who approves, and how: A controller, from the review queue. The agent creates no draft.
- Action: An invoice total above the limit Finance set for automatic matching | Who approves, and how: A controller. Above the second limit, the Head of Finance.
- Action: Bank details on the invoice differ from the supplier record | Who approves, and how: Finance. The agent flags the difference and never updates the record.
- Action: Posting an invoice to the ledger | Who approves, and how: Always a controller. The agent only ever creates drafts.
## 5. Platform and security requirements
- [x] One identity per agent. No shared keys, client secrets or connection strings. Shared-key access is disabled on `stfinanceprod`; the ERP is reached with the managed identity through Entra app roles.
- [x] Role assignments at the narrowest scope that works. Two container-scoped storage roles and one queue-scoped Service Bus role. No resource-group or subscription role.
- [x] Private access for sensitive services. Storage and Service Bus over private endpoints; public network access disabled on both.
- [x] Outbound connections limited to the destinations named under 2. The runtime reaches the ERP API, storage and Service Bus over private endpoints; all other outbound traffic is blocked at the network.
- [x] Diagnostics and logging on for every resource it touches. Diagnostics to `law-finance-prod`. Every run logs invoice id, purchase order matched, operation and result.
- Other requirements from the platform or security team: Finance baseline: the agent's prompt and tool list are deployed from the repository and never edited in the portal.
## 6. Temporary exceptions
- Exception: The ERP test environment still needs an API key, kept in Key Vault, until the vendor supports managed identity. | Owner: Integration team lead | Expires: 2027-01-31
- Exception: Read access to last year's invoices in `invoices-inbox` until the archive move to cold storage is done. | Owner: Finance | Expires: 2026-12-15
## Agreed by
- Business sponsor: Head of Finance, 2026-11-03
- Data owner(s): Finance and Procurement, 2026-11-03
- Builder: Integration team lead, 2026-11-03
- Platform or security: Cloud platform team, 2026-11-03
