AI agents need their own access rules
Identity and access management was built around people: a joiner, a mover and a leaver, judgement before each action, and a periodic access review. An AI agent has none of these. It is created rather than hired, acts on whatever text reaches it, works at machine speed and often runs under a shared account or a person's own login.
- Sources retrieved
- 19 October 2026
- Series
- Securing AI agents and bots
- Format
- Briefing and full PDF report
- Reading time
- 4 minutes here, 10 for the full report
The full report is a PDF, sent by email on request.
- 10access and governance risks specific to AI agents
- 8agent-native rules that answer them
- 9published sources behind the full report
- 6practical steps to start, in the full report
Summary
Key findings
- Rules written for people leave an agent governed by assumptions that do not hold. There is no joiner, mover or leaver event, no judgement before each action, and no review cycle fast enough to matter.
- The risks are access and governance risks, not model risks. They include excessive agency, injected instructions that borrow the agent's permissions, inherited privileges, standing secrets, agents with no leaver event and no owner, and actions that outrun every human review cycle.
- The starting question is least privilege for something unpredictable. The NIST draft concept paper on agent identity asks how to establish least privilege for an agent "especially when its required actions might not be fully predictable when deployed" (NIST NCCoE, draft, February 2026).
- Eight rules answer the risks. They limit what a misled or compromised agent can do, and make sure someone is accountable when it happens.
Context
Why human rules break
Human access control rests on five assumptions. An agent breaks every one of them, which is why a rule written for a person cannot simply be applied to it.
| Assumption | A person | An AI agent |
|---|---|---|
| Lifecycle | Joins, moves and leaves through a human resources process that changes access | Created by a developer or business user, with no leaver event |
| Judgement | Applies judgement before acting and usually notices a request that looks wrong | Acts on whatever text reaches it, including text written by an attacker |
| Pace | Works at human speed, so a periodic review is fast enough | Works at machine speed |
| Proof | Signs in with a password and a second factor that prove presence | Authenticates with keys and tokens, not presence |
| Accountability | A named person answers for what the account does | Actions are often logged to a service account or the user who started it |
Source: IAM Tech research, October 2026.
Findings
Ten access and governance risks
The risks are drawn from published guidance by the Open Worldwide Application Security Project (OWASP), the UK National Cyber Security Centre (NCSC), NIST and the Model Context Protocol (MCP) specification, and from one AI vendor's own report of a misuse of its product. The full report cites the source for each.
- 1Excessive agency: more tools, permissions or autonomy than the task needs
- 2Injected instructions that borrow the agent's permissions
- 3Privileges inherited through delegation
- 4Standing secrets
- 5No leaver event and no owner
- 6Speed and scale beyond any human review cycle
- 7Tools added without review, and scopes granted up front
- 8Shared identities
- 9Untraceable actions
- 10Human approval overwhelmed by volume
Source: IAM Tech research, October 2026. Each risk is documented in published guidance; the full report names the source.
Recommendations
Eight agent-native rules
These are rules designed for what an agent is, rather than adapted from rules for people. Each one answers one or more of the risks above.
- 1An identity per agent
- 2A named owner and a lifecycle record
- 3Access per task, short-lived
- 4A check at every action
- 5Privilege follows the least trusted input
- 6Delegation only narrows
- 7Human approval is reserved and tiered
- 8Every action is attributable
Source: IAM Tech research, October 2026.
None of these rules removes the risk of prompt injection, which the UK NCSC treats as a residual risk to be managed through careful design, build and operation (NCSC, 2025). Together they limit what a misled or compromised agent can do.
The full report
Request the full report
The full report sets out each risk with its published source, why the human rule fails, and the agent-native rule that reduces it, with six practical steps and the numbered references. It is the first in a series on securing AI agents and bots. A person at IAM Tech emails it to you.
Full report
AI agents need their own access rules
- Each of the ten risks with its published source
- Why the human rule fails, and the agent-native rule that answers it
- Six practical steps to start
- Nine numbered references with retrieval dates
Method
About this research
To get the full report, use the request form. The briefing and the full report are desk research by IAM Tech. They draw on published guidance from OWASP, the UK NCSC, NIST and the MCP specification, on one independent researcher's published analysis, and on one AI vendor's own account of a misuse of its product. Every source is listed in the full report with the date it was retrieved.
Two limits are worth knowing. Some of the OWASP material for agents is working-group draft text that preceded the final list, and the full report says so where it is cited. The vendor account is a self-report and has not been independently audited. None of the rules removes a risk entirely.