> For the complete documentation index, see [llms.txt](https://www.aicontrolarchitecture.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.aicontrolarchitecture.org/the-ten-pillars/08-pillar-ai-identity-and-access-control.md).

# 08 · Identity & Access Control

**Control question:** *Under what identity, and with what access, does the AI act?* **Surface:** See (and the foundation of Do).

***

## Purpose

When an AI accesses systems or takes actions, it does so under some identity with some access. This pillar ensures that identity is **distinct, bounded, least-privileged, and revocable**, not a human user's standing credentials, and not a broad service account inherited by convenience. It is the difference between an actor you can attribute and constrain, and one you cannot.

***

## Why it matters

The most common, and most dangerous, shortcut in enterprise AI is letting the AI act *as the user*, with the user's full access. It feels natural (the copilot helps *me*, so it uses *my* permissions) and it is a control failure: a probabilistic system now wields a human's entire standing authority, across everything that human can reach, with none of the human's judgment. Agents make it worse: they run continuously, at machine speed, often with credentials broad enough to "just work." Identity is where you decide whether the AI is a bounded actor or an unbounded one.

***

## Control objectives

* Give each AI use case a **distinct non-human identity**, separate from the users it serves.
* Grant that identity **least-privilege** access scoped to the use case's actual need.
* Make access **promptly and completely revocable**.
* Make every consequential action **attributable** to the identity and the grant that authorized it.

***

## Requirements

From the [Requirements Catalogue](/foundation/06-requirements-catalogue.md):

| ID        | Requirement                                                                        | From | Boundary |
| --------- | ---------------------------------------------------------------------------------- | ---- | -------- |
| ACA-08-01 | AI acts under a distinct non-human identity, not a user's standing credentials.    | T2   | Verified |
| ACA-08-02 | AI identities are granted least-privilege access scoped to the use case.           | T2   | Verified |
| ACA-08-03 | AI access is revocable promptly and completely.                                    | T2   | Verified |
| ACA-08-04 | High-tier actions are attributable to the identity and grant that authorized them. | T3   | Enforced |

***

## Key controls

* **Dedicated AI identity**: a service/workload identity per use case (or per agent), issued and governed like any other privileged identity, never a shared human login.
* **Scoped, least-privilege access**: permissions derived from what the use case actually needs to See and Do, default-deny, reviewed as scope changes.
* **On-behalf-of with constraint**: where the AI must act for a user, it does so through a delegation that is *narrower* than the user's full rights and carries the user's context for attribution, not the user's blanket authority.
* **Short-lived credentials & revocation**: prefer short-lived, rotatable credentials; ensure a fast, complete kill path (ties to [pillar 16](/the-ten-pillars/16-pillar-containment-and-recovery.md)).
* **Attribution**: every action carries the AI identity and, where relevant, the human and grant behind it, so [monitoring](/the-ten-pillars/15-pillar-monitoring-and-evidence.md) can reconstruct who authorized what.

***

## No standing authority

Per [principle 3](/foundation/04-architecture-principles.md), authority is granted for a purpose and revocable, not a permanent property of the AI. In practice: prefer just-in-time, scoped grants over broad standing access; treat every high-impact action as exercising a specific grant that can be withdrawn. This is what makes an AI's authority *reversible* at the identity layer.

***

## Tier guidance

|                        | T1          | T2                  | T3                  |
| ---------------------- | ----------- | ------------------- | ------------------- |
| Distinct AI identity   | Recommended | Required            | Required            |
| Least-privilege scope  | Recommended | Required (verified) | Required (verified) |
| Prompt revocation      | -           | Required            | Required (tested)   |
| Per-action attribution | -           | Recommended         | Required (enforced) |

***

## Evidence

The [AI Identity & Access Control template](https://github.com/ai-ankqush/ai-control-architecture/tree/main/templates/ai-identity-and-access-control-template.md) captures the identity, its scope, the grant model, and the revocation path. Boundary source reaches *Verified* when access scope is confirmed against the live system, and *Enforced* when a control point actually blocks out-of-scope access.

***

## Standards crosswalk

Maps to NIST AI RMF **Manage**, ISO/IEC 42001 access and operational controls, EU AI Act (access governance for high-risk systems), NYDFS Part 500 (access controls, least privilege), and OWASP LLM (excessive agency / insecure access). See [`mappings/`](/standards-crosswalks/mappings-readme.md).

***

## Failure modes

* The AI runs as the user, with the user's full access.
* A broad service account shared across many use cases, no scoping, no attribution.
* Long-lived static credentials with no revocation path.
* An agent whose actions cannot be traced to an identity or a grant.

***

**Next:** [09 · Data Boundary Control](/the-ten-pillars/09-pillar-data-boundary-control.md)

*Version 0.1.0 · Licensed under the terms in* [*LICENSE.md*](https://github.com/ai-ankqush/ai-control-architecture/tree/main/LICENSE.md)*.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.aicontrolarchitecture.org/the-ten-pillars/08-pillar-ai-identity-and-access-control.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.