Most AI agents get their identity the same way a script did in 2010: someone creates a service account, pastes a key into a config file, and nobody records who owns it, what it can touch or when it should stop. This template is a fillable request form that a team completes before [Organisation] issues an identity to a new AI agent. It captures the accountable owner, the agent's purpose, the tools and scopes it needs, the data classes it will reach, the credential type and the expiry date, and it turns those answers into an approval route and a registry entry. It assumes the use case itself has already been approved through the AI Use Case Intake Form Template: intake asks "should we do this", this form asks "what identity, with what access, for how long". It is for identity and access teams, platform engineers who build agents, and the owners who will answer for them.
How to use this template
- Copy sections 3 to 10 into your request tool (IGA access request, ITSM catalogue item or a form that writes to the agent registry). Keep the field IDs so answers can drive approval rules and provisioning automatically.
- Replace text in square brackets, such as [Organisation], [IAM team], [90 days] and [Agent registry], with your own values. Bracketed values are NHI Mgmt Group suggestions, not requirements of any standard.
- One form per agent identity. An agent that runs in development, test and production gets one form per environment, because the scopes, data and credentials differ. Reusing one identity across environments is a named risk (OWASP NHI8:2025 Environment Isolation and NHI9:2025 NHI Reuse).
- The form requests an identity and its access; it does not assess the use case. If answers in Part B change the purpose or data recorded at intake, send the request back to intake.
- Every approved form creates the entry described for the AI agent registry. The registry ID is the key that later links credentials, logs, recertification and decommissioning.
1. Purpose
This form gives [Organisation] a single, auditable request for every new AI agent identity. It makes sure that before any credential exists the agent has a named accountable owner, a stated purpose, a minimal and justified set of tools and scopes, a known ceiling on the data it can reach, an approved credential type and an expiry date. It supports NIST SP 800-53 Rev. 5 AC-2 Account Management (accounts are requested, approved and assigned an owner), IA-4 Identifier Management, IA-5 Authenticator Management and AC-6 Least Privilege, and NIST CSF 2.0 PR.AA-01 and PR.AA-05.
2. Scope and when the form is required
- New agents: before any identity, service principal, workload identity, API key, OAuth client or agent user account is created for an AI agent that will act in [Organisation] systems or on [Organisation] data.
- Material change: when an existing agent gains a new tool, a broader scope, a higher data class, a new environment, or moves from acting on a user's behalf to acting autonomously. Submit a change request on this form with the existing registry ID.
- Vendor-hosted agents: when a SaaS product's agent feature is granted a connection, OAuth consent or API token into [Organisation] systems. The owner is the [Organisation] person who grants the connection.
- Out of scope: a user's own assistant that runs only with that user's interactive session and no stored credential is covered by the AI acceptable use policy, unless it is given standing tokens or scheduled triggers.
3. Part A: Ownership and accountability
No identity is issued without A1 and A2. An agent with no reachable owner is the starting point for most orphaned NHI findings (OWASP NHI1:2025 Improper Offboarding).
| ID | Field | Answer type |
|---|---|---|
| A1 | Accountable owner: the named person who answers for the agent's actions, approves its access and attests at recertification | Directory lookup (person, not a group) |
| A2 | Backup owner, or owning group, who takes over if A1 moves or leaves | Directory lookup |
| A3 | Technical custodian: the team that builds, deploys and rotates credentials for the agent | Team name and on-call contact |
| A4 | Business unit and cost centre | Picklist |
| A5 | Approved use case reference from AI intake | Intake ID (mandatory) |
| A6 | Incident contact who can decide within [1 hour] whether the agent's behaviour is expected | Person and phone |
4. Part B: Purpose and operating model
| ID | Field | Answer options |
|---|---|---|
| B1 | Agent name, following the [Organisation] naming standard (see the Machine Identity Naming and Tagging Standard Template) | Text, validated against pattern |
| B2 | One-sentence purpose: what task the agent completes and for whom | Text |
| B3 | Things the agent must never do (negative scope), for example "never sends external email", "never approves payments" | Text, at least one line |
| B4 | Access mode | Acts on behalf of a signed-in user / acts autonomously under its own identity / both / don't know |
| B5 | Autonomy level (see the AI Agent Autonomy Levels Framework) | Suggests only / acts with human approval per action / acts and reports / acts unsupervised |
| B6 | Trigger | User prompt / schedule / event or webhook / another agent / multiple |
| B7 | Hosting and runtime | [Organisation] cloud account or cluster (state which) / vendor SaaS / developer workstation / other |
| B8 | Environment for this request | Development / test / production |
| B9 | Does the agent call or get called by other agents? | No / yes (list registry IDs) / don't know |
B4 matters more than any other field in this part. On-behalf-of access inherits a user's rights and needs delegation controls; autonomous access needs its own tightly scoped grant. RFC 8693 (OAuth 2.0 Token Exchange) separates the two clearly: under delegation the actor keeps its own identity and the token can carry an act claim naming it, while under impersonation the actor is treated as the subject. Ask for delegation where the platform supports it, so logs show both the user and the agent. See AI Agent Service Accounts vs On-Behalf-Of Access.
5. Part C: Tools, connections and scopes
List every tool, API, MCP server and SaaS connection the agent will use. One row per tool. Requests for "all scopes", wildcard resources or administrator roles are returned unless C7 is completed.
| ID | Field | Example answer |
|---|---|---|
| C1 | Tool or system name and registry or CMDB ID | Ticketing system, APP-0412 |
| C2 | Connection type | REST API / MCP server / database / SaaS OAuth app / cloud control plane / shell or code execution |
| C3 | Exact scopes, roles or permissions requested | tickets.read, tickets.comment |
| C4 | Read, write, delete or execute | Read and write (comments only) |
| C5 | Resource boundary: which projects, tenants, folders or queues | Queue "IT-Service-Desk" only |
| C6 | Actions that need a human approval step before execution | Closing a ticket; any write outside the queue |
| C7 | Justification for any privileged, wildcard or cross-tenant permission, and why a narrower one will not work | Text, reviewed by [IAM team] |
| C8 | For MCP servers: server owner, version or commit pinned, and whether it is on the [Organisation] approved list | Internal server, v1.4.2, approved |
Tool access is where excessive agency turns into impact. OWASP lists Tool Misuse and Exploitation (ASI02) and Identity and Privilege Abuse (ASI03) in its Top 10 for Agentic Applications, published in December 2025. See the OWASP Agentic Top 10 ASI03 Guide and the MCP Security Guide.
6. Part D: Data classes and boundaries
| ID | Field | Answer options |
|---|---|---|
| D1 | Highest data classification the agent can read through any tool in Part C | [Public / Internal / Confidential / Restricted] |
| D2 | Highest classification it can write or send | Same list |
| D3 | Personal data categories reachable | None / employee / customer / special category / children / don't know |
| D4 | Can it reach credentials, secrets, keys or security configuration? | No / yes (which) / don't know |
| D5 | Where does output go? | Back to the requesting user only / internal systems / external parties / public |
| D6 | Does the agent keep memory, a vector store or logs containing D1 data beyond one session? Where, and for how long? | No / yes (store, retention) |
| D7 | Does it read untrusted content (inbound email, web pages, uploaded files, tickets from customers)? | Yes / no / don't know |
D1 should be checked against the tools, not taken on trust: an agent with read access to a shared drive can reach the highest class stored there. D7 combined with write access in C4 and external output in D5 is the pattern that lets injected instructions move data out, so that combination always goes to the security route in section 9. See the AI Agent Memory Security Guide.
7. Part E: Identity and credential
| ID | Field | Answer options |
|---|---|---|
| E1 | Identity type requested | Platform agent identity object / workload identity (federated) / cloud service principal or role / OAuth client / dedicated service account / agent user account |
| E2 | Credential type | Federated token from the runtime (no stored secret) / certificate or private key in a managed store / client secret / API key / password |
| E3 | Where the credential is stored and who can read it | [Secrets manager path] and reader list |
| E4 | Token lifetime and rotation interval | Access token [1 hour]; stored secret rotation [90 days] maximum |
| E5 | Is this identity used by anything other than this agent? | Must be "no" |
| E6 | Can a human sign in with it? | Must be "no" (OWASP NHI10:2025 Human Use of NHI) |
| E7 | Network or source restriction | Allowed source workloads, IP ranges or conditional access policy |
Default to E2 option one. Federated tokens issued to the runtime remove the stored secret, which addresses OWASP NHI2:2025 Secret Leakage and NHI7:2025 Long-Lived Secrets at once. Static API keys and passwords need a written exception under C7 and the shortest rotation the target system allows. Credential handling after issue is covered in the AI Agent Credential Lifecycle and Rotation Guide.
8. Part F: Expiry, monitoring and exit
| ID | Field | Answer options |
|---|---|---|
| F1 | Identity expiry date (hard end date, after which access is disabled unless renewed) | Date, maximum [12 months] production, [30 days] pilot |
| F2 | Recertification interval | [Quarterly] for Restricted data or write access, [six-monthly] otherwise |
| F3 | Log destination for the agent's authentication events and tool calls | [SIEM index or workspace] |
| F4 | Kill switch: who can disable the identity, and how, within [15 minutes] | Named role and method |
| F5 | Decommission trigger | Expiry / owner leaves without successor / use case retired / [N] days unused |
F4 is tested before go-live, not written down and forgotten. See the AI Agent Kill Switch and Containment Guide, and the AI Agent Decommissioning Checklist for what F5 sets in motion.
9. Approval routing
Routing is computed from the answers. The highest route triggered wins.
| Route | Triggered by | Approvers | Target time |
|---|---|---|---|
| Standard | D1 at Internal or below, read-only in C4, federated credential in E2, B5 "suggests only" or "approval per action" | Owner (A1) and [IAM team] | [2 working days] |
| Elevated | Any write or delete in C4, D1 Confidential, B4 autonomous, B6 schedule or event, or a stored secret in E2 | Owner, [IAM team], system owner of each tool in C1 | [5 working days] |
| Security review | D1 Restricted, D4 yes, any C7 justification, D7 yes with write access and external output, B9 yes, or B5 "acts unsupervised" | Above plus [Security architecture] and, for personal data, [Privacy] | [10 working days] |
| Return to requester | A1 missing, A5 missing, E5 or E6 answered "yes", or any "don't know" in Parts C to E | None: the form is incomplete | Not applicable |
A tool's system owner approves scopes on their own system. This mirrors the way application owners approve entitlements when an application is brought under governance; see the Entitlement Catalogue and Application Onboarding Guide.
10. Provisioning record and sign-off
- Registry entry: [IAM team] creates the registry record with the agent name, registry ID, owner, backup owner, purpose, access mode, environment and expiry from this form.
- Identity created: identifier, identity type and creation date recorded against the registry ID.
- Grants applied: each scope in C3 granted exactly as approved, with the approver and date per grant.
- Credential issued: storage location, rotation schedule and expiry recorded; secret values are never pasted into the form or ticket.
- Logging verified: a test call appears in the F3 destination tagged with the registry ID.
- Kill switch tested: identity disabled and re-enabled once, with the time taken recorded.
- Owner attestation: "I am accountable for this agent's actions, I will keep this record current, and I will request removal when it is no longer needed." Name, date.
Implementation guidance
Rolling the form out
- Inventory first: before enforcing the form, find the agent identities that already exist (OAuth grants to AI apps, service principals created by agent platforms, API keys in agent configs). Backfill a form for each, starting with those that have write access or Restricted data.
- Pilot with one platform team for [four weeks]. Measure how many submissions come back incomplete and which fields cause "don't know" answers, then reword.
- Make the form the only path. Remove standing rights for developers to create service principals, OAuth clients or agent identities in production; grant them through the provisioning step instead. Keep a break-glass route that requires a retrospective form within [2 working days].
- Automate the routing from the field values so requesters see the route and timeline when they submit.
- Connect expiry to enforcement. F1 must disable the identity automatically. A date in a spreadsheet does not expire anything.
Decisions to make before you publish it
- Who may be an owner: a person in the business who benefits from the agent, not the developer by default. Developers can be technical custodians (A3).
- Small organisations: collapse the Standard and Elevated routes into one approval by the owner and one IT lead, but keep Part E and the expiry date unchanged.
- Large organisations: feed the form from the IGA platform so agents appear in the same certification campaigns as other accounts; see Agent Identity Recertification.
- Vendor agents: decide whether a SaaS agent's OAuth consent counts as a new identity. NHI Mgmt Group suggests yes whenever the consent grants write scopes or offline access.
Measuring it
- Coverage: share of known agent identities with a current, approved form and registry ID.
- Ownerless agents: count of agent identities whose A1 and A2 have both left or moved, per month.
- Static credential share: proportion of agent identities using API keys, client secrets or passwords rather than federated tokens.
- Expired but active: agent identities past F1 that still authenticated; the target is zero.
- Scope reduction at review: share of requests where approvers narrowed C3 before approving, as a signal of how often teams over-ask.
Framework mapping
| Form part | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | OWASP NHI Top 10 2025 |
|---|---|---|---|
| A (ownership) | AC-2 | GV.RR-02 | NHI1 Improper Offboarding |
| B (purpose, naming) | IA-4, CM-8 | ID.AM-02 | NHI9 NHI Reuse |
| C (tools, scopes) | AC-3, AC-6 | PR.AA-05 | NHI5 Overprivileged NHI |
| D (data) | AC-16, SC-28 | PR.DS-01 | NHI8 Environment Isolation |
| E (credential) | IA-5 | PR.AA-01 | NHI2, NHI4, NHI7, NHI10 |
| F (expiry, logging) | AC-2, AU-2, AU-12 | PR.AA-05 | NHI1 Improper Offboarding |
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST NCCoE: Software and AI Agent Identity and Authorization project
- OWASP: Non-Human Identities Top 10 2025
- OWASP GenAI Security Project: Top 10 for Agentic Applications
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- OpenID Foundation: Identity Management for Agentic AI
Related NHI Mgmt Group resources: AI Agent Lifecycle Management Guide, AI Agent Authorisation Guide, AI Agent Risk Assessment Template, Agent Identity and Access Guide.