Attribute-Based Access Control for AI at the Request Boundary

Attribute based access control AI policy should decide whether an identified caller may send a classified request to a model route under the current conditions. A platform team can express that decision with five fields carried on an HTTP request. For example, employee u-1842 acting through agent invoice-reviewer-v3 requests invoke on azure-openai/eu/gpt-5, with finance-confidential content during an approved workflow. Each value needs an authoritative source and a freshness rule. It also needs a defined result when missing.

TL;DR

• ABAC evaluates each AI request using verified subject and resource attributes, plus action, content, and environment attributes, against a versioned policy.
• Define the attribute contract before writing rules. Include the issuing system and allowed values, plus the freshness limit and missing-value behavior.
• Deny ambiguous requests and test stale identity with absent classification. Also test route substitution and policy-version changes before release.
• Keep model-route authorization separate from tool and database authorization, as well as memory and local-process authorization, because those actions have different enforcement points.

Attribute based access control AI uses a decision tuple

NIST Special Publication 800-162 defines ABAC as authorization determined by evaluating attributes associated with the subject, object, requested operation, and sometimes environmental conditions against policy. The NIST ABAC definition and considerations provide the underlying model. Applying it to an AI request requires an explicit translation rather than a new access-control theory.

The subject is the human or the workload or agent initiating the request, including tenant and role. The object is the model route or deployment being reached. The operation is usually invoke, although administrative actions such as changing a model alias belong in a separate policy set. Request attributes describe the assembled prompt, including its data classification and originating application. Environmental attributes capture time and deployment region, along with device posture and an active incident restriction.

That tuple gives the AI policy engine something deterministic to evaluate. A rule can permit a finance analyst to send internal data to an approved regional deployment while denying finance-confidential content on an evaluation route. The policy decision attaches to one request and one route. It also records one policy version.

Define the attribute contract before policy rules

Policy code written before the attribute contract usually turns missing context into accidental permission. Define each field as an interface connecting the identity provider and application with the classifier, model registry, and enforcement point. The contract should state four properties for every attribute:

• Issuer: the system allowed to assert the value, such as the corporate identity provider for department or the model registry for approvedDataClasses.
• Vocabulary: the exact allowed values and their meaning, including the difference between internal and finance-confidential.
• Freshness: the maximum age of the assertion and the event that forces reevaluation.
• Failure behavior: the decision when the field is absent or malformed, stale, or signed by an untrusted issuer.

An application-supplied role=admin string has little value without issuer verification. A classifier result also needs the classifier version and timestamp because a later model may assign a different label to the same prompt. The identity-aware AI gateway architecture places these inputs on the request path before policy evaluation.

I would reject a production ABAC design that treats unknown as a lower sensitivity level. Unknown leaves the control without enough information to authorize the route. The practical default denies the request or sends it to an explicitly approved low-risk path that accepts only public data.

Deny cases make the policy testable

A useful test suite starts with denied requests because they expose which attribute actually controls the outcome. Give every case a request ID. Freeze the identity claims and prompt classification, plus the route metadata, environment, and policy bundle used in the decision.

Start with a valid identity whose department attribute has expired. Follow it with an active identity and a missing prompt classification. Change only the model alias so an approved production deployment becomes an evaluation endpoint. Then keep the request constant while advancing the policy version to one that removes the caller's role. Each case should produce a specific reason code. A generic forbidden response cannot identify the failed condition.

NIST Special Publication 800-207 describes zero trust as accurate, least-privilege per-request access decisions and says resource access should be governed by dynamic policy using identity and application or service state, plus the requesting asset and environmental attributes. The NIST Zero Trust Architecture also separates the policy decision from the policy enforcement point. For AI traffic, the HTTP proxy can act as the enforcement point only for requests deliberately routed through it.

Test route bypass as a separate case. A clean denial on the managed hostname proves little if the application still holds a provider key that reaches the model directly. Network policy and credential custody must combine with deployment configuration to force the intended request path.

Model authorization ends before tool execution

An LLM response may propose a database query or email send, as well as a file write or payment-review ticket. The ABAC decision on the model request authorizes none of those effects. It permits a caller to use a particular model route with a particular payload under current policy.

The action service needs its own subject and resource, along with an operation and environment. Its subject may include the originating user plus the agent workload. Its resource may be the customer record or mailbox, the file, or the transaction. The requested operation changes to read or send, write, or another capability owned by that service. This separation is the practical boundary described in AI agent tool permissions.

Keep correlation without merging authority. Pass a request ID with verified delegation context to the downstream service, then let that service evaluate its own policy. A model-route permit can appear beside a tool-call denial in the same trace. That pair shows the controls working at separate boundaries. The first allowed inference. The second prevented an unauthorized effect.

DeepInspect operates on authenticated HTTP traffic between users or agents and LLM endpoints when that traffic is routed through its proxy. Database ACLs and queue permissions remain with their respective systems, as do local subprocess controls, vector-store namespaces, and SaaS authorization.

The decision record preserves the attribute snapshot

A permit or denial needs enough evidence for another engineer to reproduce the outcome. Record the request ID and subject identifiers, plus the agent or workload identity and target route. Include the operation and content classification, relevant environment fields, policy identifier, policy version, decision, reason code, and timestamp. Preserve attribute provenance and freshness data beside the values used.

Avoid dumping an entire identity token or raw prompt into every record. The evidence schema should capture the claims and classifications required to explain the decision, with sensitive payload handling governed by its own retention and access policy. The full prompt may belong in a restricted evidence store, while the decision record carries a content hash and classification result.

A reviewer should be able to put one denied record next to the policy bundle and locate the failing condition in a minute. If the record says only 403 policy violation, the system produced an outcome without usable action lineage. The same test should work after policy deployment changes, which is why version identifiers belong in every record rather than in a separate release log.

DeepInspect

DeepInspect can enforce an ABAC decision on authenticated HTTP requests deliberately routed to LLM endpoints. It evaluates application-supplied identity and agent context alongside request classification and model destination under the active policy. The resulting permit or denial is bound to a policy version and written as a per-decision record. Redaction can also be recorded as the result.

The surrounding architecture still owns identity issuance and attribute quality. It also owns classifier governance, model-registry accuracy, and bypass prevention. Tool services and data stores make separate authorization decisions for their resources. DeepInspect covers the model-request boundary and leaves those adjacent controls with the systems able to enforce them.

Book a technical deep dive at deepinspect.ai.