An AI integration can reach a business system. The connection alone does not establish its continuing purpose, owner, allowed actions or end condition.
An AI-agent permission is the complete operating decision that links an identity and authority source to a resource, action, data class, duration, approval rule, evidence record and revocation path. This is an IZZY working definition, not an external standard.
The practical question is how to manage AI agent permissions as a lifecycle, not as a list of app connections.
Answer in 60 seconds
- Inventory active and dormant AI integrations, automations and agent workflows.
- Assign a business owner and a technical owner to each one.
- Record whether it uses a named user’s authority, a workload identity, temporary access or a shared credential.
- Scope the grant by resource, action and duration.
- Attach approval to the exact consequential action and its parameters.
- Record attempts, decisions and results without recording credentials or secrets.
- Set review triggers, expiry conditions, a stop procedure and a tested revocation path.
Keep those decisions in an agent access register: a maintained IZZY operating record, not a technical agent directory, compliance certificate or legal register.
In this article
- What counts as an AI agent permission?
- Where does permission debt appear?
- What belongs in an agent access register?
- Which identity and access model should you use?
- How should approvals, logs and delegation work?
- How do you review and revoke access?
1. What counts as an AI agent permission?
For operating purposes, treat each permission as nine connected decisions:
identity + authority source + resource + action + data class + duration + approval + logging + revocation
- Identity: the user, application or workload presenting the request.
- Authority source: the person or business mandate behind it.
- Resource: the bounded tenant, mailbox, folder, repository, project, table or records.
- Action: search, read, draft, create, update, send, publish, delete, approve or administer.
- Data class: personal, confidential, client, financial or other restricted information.
- Duration: one request, task, pilot or continuing access with a review trigger.
- Approval: the exact action needing another decision.
- Logging: the attempt, decision and result available for review.
- Revocation: the identity, grant, session, job or delegated route that must stop.
This broader definition matters because a consent screen or role assignment records only part of the operating decision.
Agent identity and authorisation are developing areas. A 2026 NIST NCCoE concept paper explores identification, authorisation and auditing for software and AI agents. It is an initial public draft, not a final standard. NIST’s AI Agent Standards Initiative describes related work on authentication and identity infrastructure.
Do not wait for one universal model. Make permissions visible, apply established practices and document what the architecture cannot express.
2. Where does permission debt appear?
Permission debt is the gap between access that exists and access the organisation can still explain, review and end. The following five patterns are an IZZY diagnostic model, not measured prevalence.
| Pattern | Operating problem | Decision to reopen |
|---|---|---|
| No accountable owner | An administrator can maintain the connection, but nobody owns its continuing business purpose. | Name who can renew, change or retire the access. |
| Ambiguous authority | A human session or shared credential hides which workflow acted and under whose mandate. | Separate the identity or record the authority path. |
| Accumulating scope | New resources and actions are added while older grants remain. | Compare the current grant with the current job. |
| No end condition | Access has no expiry, renewal decision or material-change trigger. | Define when the decision must be reopened. |
| Hidden delegation | One service invokes another without preserving the initiating authority and intermediate route. | Make the delegation path reviewable or redesign it. |
3. What belongs in an agent access register?
An agent access register gives product, operations, platform and security stakeholders one maintained view of the permission lifecycle. It should record:
- integration or agent name, purpose and owners;
- identity, authority source and credential type;
- connected systems, resources, actions and data classes;
- approval rule, duration, expiry and review trigger;
- attempted and completed action records;
- delegation path; and
- revocation and stop procedure.
These IZZY-defined fields can live in an existing service catalogue, identity system, risk register or operating document. A dedicated tool is not the first requirement.
Consider a support-triage workflow that classifies cases and prepares draft replies. An application identity reads one queue and selected knowledge articles. A support operator approves sending. Changes to the queue, data class, provider or available actions trigger review. Revocation disables the grant and checks pending jobs before manual operation resumes.
Access to support would not tell a reviewer which queue, actions, authority or revocation behaviour applies.
Microsoft Entra Agent ID provides one product example separating technical owners from business sponsors. It is not a universal model, but the distinction makes administration and continuing business accountability explicit.
4. Which identity and access model should you use?
AI agent identity management begins with choosing whose authority the workflow uses.
- User-delegated authority preserves a named user’s context and should remain within the approved purpose. Microsoft documents delegated and app-only sign-in activity in one product.
- Application or workload authority provides a separate technical identity. It can improve visibility and independent revocation, but does not prove human intent.
- Temporary task authority exists for a bounded operation. Its lifetime depends on the task, system and consequence.
- Shared authority covers several workflows with one credential, limiting distinction and independent revocation.
Least privilege for AI agents requires explicit resource, action and duration decisions:
| Dimension | Decision the owner must record |
|---|---|
| Resource | Which tenant, mailbox, folder, project, repository, table or record set? |
| Action | Read, search, draft, create, update, send, publish, delete, approve or administer? |
| Duration | One request, session, task, pilot or standing access with a named review trigger? |
| Authority | Which user, application, workload or temporary identity? |
| Consequence | Which exact action requires independent approval or another execution path? |
| Evidence | Which attempt, permission decision and result are recorded without secrets? |
This table is an operating framework, not a universal access-control standard.
RFC 9700 recommends restricting OAuth token privileges and binding them to intended resources and actions. For MCP implementations, the authorisation specification supports requesting additional scopes when needed. Neither protocol represents the whole permission lifecycle.
The UK NCSC recommends minimum access for the shortest necessary period, temporary credentials where possible and revocation when work ends. This does not create one expiry period for every integration.
5. How should approvals, logs and delegation work?
Installation and action approval are different decisions. For sending, publishing, deletion, record changes or access changes, bind approval to the exact target and displayed parameters. CRM access cannot replace a decision about a particular update.
OWASP’s AI Agent Security Cheat Sheet recommends limiting tools and permissions and explicitly authorising sensitive operations. Enforcement belongs in the application or policy layer, not the model’s judgement.
Logs should help a reviewer answer three questions:
- What was attempted - the tool, target, action and relevant parameters?
- What was decided - the acting identity, authority source, applicable rule and approval result?
- What happened - completed, denied, failed, reversed or stopped?
Do not record authorisation headers, tokens, credentials or secrets. MCP’s authorisation guidance states this for MCP implementations.
When one integration calls another service, record the initiating authority, intermediate client, target and outcome where supported. MCP’s security guidance explains that token passthrough can obscure client identity and downstream audit trails. Other delegated architectures need the same operating answer, though their controls differ.
Logs support review; they do not prove intent or complete attribution.
6. How do you review and revoke access?
Start with one bounded portfolio: a team, product, process or group of integrations that reach the same systems.
- Inventory. Compare app dashboards, identity records, automation platforms, secret stores and team knowledge. Record active, dormant and unresolved routes.
- Classify. Name the owners, purpose, authority, resources, actions, data classes, duration and highest-consequence action.
- Narrow. Remove unused systems, actions and broad scopes where more precise grants are supported. Separate workflows needing different owners or revocation paths.
- Add review triggers. Reopen the decision when purpose, owner, system, data, action, provider, credential or consequence changes.
- Test stop and revocation. Disable the identity or grant; inspect sessions, tokens, delegated services, queued work and scheduled jobs. Confirm the fallback.
- Assign operation. Name who reviews renewal, monitors exceptions and can suspend the workflow.
The result may be a narrower grant, separate identity, architectural change or retirement. The register matters only when it changes a grant, renewal or revocation decision.
Pause before expansion when a workflow involves personal or regulated data, crosses organisational boundaries, enables high-consequence actions, relies on an inseparable privileged identity, hides delegation or fails a stop test.
For personal data, the European Commission describes purpose limitation, data minimisation and storage limitation. Applying them to legal basis, roles, notices, transfers or impact assessment requires qualified review.
IZZY can map product, identity, cloud and operating choices. Legal, privacy, security and sector specialists should own conclusions in their domains.
Conclusion: treat access as a lifecycle
A connection is a technical fact. A permission is a continuing business and operating decision.
Keep the purpose, owner, authority, resource, action and duration visible. Connect approval to consequences, preserve the delegation path and test how access stops. When the workflow changes, reopen the grant instead of inheriting yesterday’s decision.
Map one AI-access portfolio
Bring one bounded list of AI tools, automations and agent workflows, the systems they reach, known owners and any available scope, log, expiry or revocation records. In a 30-minute scoping call, IZZY can map the first agent access register, identify unresolved decisions and compare implementation paths across product, cloud and identity.
Frequently asked questions
No. It records part of an authorisation flow. The operating decision also needs purpose, ownership, resource, action, duration, delegation, evidence and revocation.
No universal rule fits every system. Separate workload identity can improve visibility and independent revocation; delegated access can preserve user context. Avoid shared authority the team cannot operate.
Use a suitable scheduled review plus event-based triggers. Reopen access when its purpose, owner, resource, data, action, provider, credential or consequence changes.
No. The register is an operating record. A formal security, legal or compliance audit has a separate scope, method, evidence standard and qualified owner.
Revoke the identity, token, role or consent; end supported sessions; stop delegated and queued work; address retained data; and record retirement or a newly approved scope.
Sources and evidence note
- NIST NCCoE: Software and AI Agent Identity and Authorization concept paper
- NIST: AI Agent Standards Initiative
- IETF: RFC 9700, OAuth 2.0 Security Best Current Practice
- Model Context Protocol: understanding authorisation
- Model Context Protocol: authorisation specification
- Model Context Protocol: security best practices
- OWASP: AI Agent Security Cheat Sheet
- Microsoft Learn: owners, sponsors and managers in Entra Agent ID
- Microsoft Learn: Entra Agent ID logs
- UK NCSC: thinking carefully before adopting agentic AI
- European Commission: data-protection principles for organisations
How this was prepared: evidence-led IZZY synthesis from current primary, official and first-party guidance. Sources checked 17 July 2026. The agent access register, permission definition, permission-debt model and review path are IZZY operating frameworks, not external standards. This article is general product and operational guidance, not a security assessment, legal opinion, privacy review, compliance determination or forecast of outcomes.