A successful login can precede an unauthorized disclosure. OWASP's Authorization Cheat Sheet requires an access decision for every request and recommends denying access by default, not trusting everything a user does after authentication. For AI systems, that distinction belongs at the center of the architecture: the model's ability to retrieve evidence or propose an action isn't permission to do either.
Why AAA Matters Beyond a Login Box
Authentication establishes identity, not authority. A customer support agent can correctly identify a customer and still retrieve another tenant's invoice. An internal assistant can act for a legitimate employee and still invoke a tool with privileges that employee doesn't possess.
These are illustrative failure modes, not reported incidents. They show why treating a valid session as a broad grant is the wrong design assumption for sensitive AI applications.
The historical AAA architecture offers a useful alternative. RADIUS originated in 1991, when Merit Network sought dial-in access controls for NSFNET and Livingston Enterprises supplied a design and initial server with its PortMaster network-access servers, according to the IETF's AAA tutorial. Its architectural contribution was the separation of the enforcement point from centralized identity and policy evaluation.
Move the trust boundary past login
In an AI stack, the enforcement point might be a retrieval service, tool gateway, or delivery service rather than a network-access server. The important question remains the same: which component decides whether this caller may perform this action against this resource?
Splash Access's authentication authorization accounting explained is a useful companion for the network-access vocabulary. Application teams need to extend that vocabulary to records, tenant boundaries, delegated actions, and the evidence used in generated answers.
A production design should provide these concrete capabilities:
- Identity separation: Distinguish the human requester from the application service and delegated agent.
- Explicit authority: Decide access against a resolved resource and requested action.
- Boundary enforcement: Keep tenant selection under trusted application control.
- Revocation handling: Stop treating earlier permission as permanent permission.
- Reconstructable evidence: Preserve the decision context alongside the resulting activity.
Design principle: A model may propose an action. A trusted enforcement component must decide whether to execute it.
This is a practical framing for large language model security: protect the interfaces through which the model acquires information and changes state. Prompt instructions can describe permitted behavior, but they shouldn't be the component that grants access.
For teams searching for an AAA authentication authorization framework, the useful distinction is between who is calling, what authority applies, and what evidence survives afterward.
The Three AAA Control Decisions Explained
AAA stands for authentication, authorization, and accounting. Treat these as separate control decisions even when a protocol combines parts of their exchange.
The diagram provides a conceptual view of the functions, not a claim that every protocol executes them in parallel.
Identity proof is not a permission decision
Authentication establishes the requesting entity's identity. Its output should be a validated principal and relevant authentication context, not an implicit permission to use every downstream capability.
Authorization evaluates whether that principal may perform a particular operation. Accounting records the activity and outcome so an operator can examine what happened later.
A worked RADIUS flow makes the separation concrete. A network-access server sends an Access-Request to the RADIUS server; an Access-Accept can return authorization attributes that constrain the service provided. RFC 2865 defines the authentication and authorization exchange and its variable-length attributes.
Accounting uses a separate Accounting-Request and Accounting-Response exchange. An acceptance decision and a session record therefore answer different questions: whether service was permitted, and what activity was subsequently recorded.
Centralize meaning, not just traffic
For an application implementation, I'd use a shared, authoritative representation of identity, tenant membership, resource ownership, and policy version. Merely routing requests through a common server doesn't ensure consistency if each enforcement point interprets those fields differently.
- Canonical principal: Use a stable identifier rather than a display name.
- Canonical resource: Resolve the object through trusted application state.
- Canonical policy context: Record which version and relevant attributes produced the decision.
- Separate outcomes: Don't equate an allowed request with a completed action.
AgentStack's discussion of agent permissions and audit logs provides an application-oriented companion to this separation.
The operational benefit is diagnostic precision. When an action fails, engineers should be able to distinguish an identity failure, an explicit policy denial, an execution error, and a missing accounting acknowledgement. Collapsing those outcomes into an undifferentiated access error makes both incident response and policy testing harder.
Authorization as the Hard Problem in AI Stacks
Authorization is the harder engineering problem because its inputs extend beyond identity. A decision can depend on the object, tenant, workflow stage, delegated principal, and current context.
OWASP's deny-by-default guidance, introduced above, establishes the baseline. My conclusion is architectural rather than a measured comparison of AI deployments: agent systems need more places to enforce authority because they perform intermediate operations on the user's behalf.
An authenticated application service may have technical access to a database while the requesting customer has permission to read only a subset of its records. If the service uses its own broad privileges without constraining them to the caller's authority, the engineer has created a confused-deputy path.
What Each AAA Control Does and Where It Breaks
| Control | Question Answered | Failure Mode | Audit Evidence |
|---|---|---|---|
| Authentication | Who or what is requesting access? | An invalid or expired identity is accepted | Principal, authentication context, session status |
| Authorization | May this principal perform this operation? | A valid identity accesses a forbidden object or tenant | Resource, action, tenant, policy version, decision |
| Accounting | What occurred under which authority? | Activity exists without enough context to reconstruct permission | Correlated decision, execution result, evidence references |
Model permissions across the workflow
Consider a support assistant that retrieves an invoice and then proposes a refund. Reading the invoice and issuing the refund are different operations. Approval to perform the former should not imply approval for the latter.
The same distinction applies within retrieval. Permission to search a collection doesn't automatically settle permission to return every matching object, reveal its provenance, or deliver its contents to a different audience.
Context can also change while work is underway. Cisco's AAA functions documentation describes dynamic RADIUS authorization that can modify or terminate an already authorized session. The application-level lesson is to design revocation as an active control, not just a condition checked at login.
Test the denials
Positive-path tests demonstrate that a permitted workflow works. They don't establish that adjacent forbidden workflows are blocked.
- Cross-tenant substitution: Replace a permitted object with an object owned by another tenant.
- Workflow escalation: Attempt a write after receiving read-only permission.
- Delegation mismatch: Present an agent identity without valid authority from the requester.
- Mid-session revocation: Remove permission before a queued action executes.
- Context manipulation: Supply a tenant or role through model-generated arguments.
- Policy failure: Return an unavailable, malformed, or stale decision.
These are proposed acceptance tests, not benchmark results. Their value is that each probes a specific assumption about who can grant authority and when enforcement occurs.
Comparing RADIUS, TACACS+, and Modern Policy Engines
Choose the control mechanism for the protected interface. A network admission decision, an administrative command, and an application object lookup aren't interchangeable operations.
The comparison below separates those enforcement models rather than ranking them.
RADIUS fits the network-edge pattern: an enforcement device requests a centralized decision and applies returned authorization attributes. Its traditional shared-secret architecture and attribute-based responses should be evaluated in the context of the actual network deployment, not treated as application-level object permissions.
TACACS+ provides independent authentication, authorization, and accounting exchanges. Cisco's comparison of TACACS+ and RADIUS documents centrally managed authorization attributes and command-level control, including the distinction between diagnostic access and configuration privileges.
For application and agent workflows, an OIDC identity layer plus an external policy decision point is an architectural option. In that proposed design, identity establishment and resource-specific permission evaluation remain separate responsibilities.
Match the mechanism to the decision
| Model | Appropriate Boundary | Decision Shape | Engineering Trade-off |
|---|---|---|---|
| RADIUS | Network access | Service permissions and configuration attributes | Network admission doesn't express every application object rule |
| TACACS+ | Device administration | Administrative service or command permission | Command control doesn't replace retrieval authorization |
| Identity layer and policy engine | Application APIs, retrieval, and tools | Subject, action, object, tenant, context | Engineers must build reliable resource resolution and enforcement |
I'd layer these controls when the infrastructure requires them. RADIUS can govern network admission, TACACS+ can govern operator commands, and an application policy engine can govern customer records. None should be used as evidence that another boundary has been secured.
Network access is permission to reach an interface. It isn't permission to perform every operation behind that interface.
The main application-layer trade-off is dependency management. An external decision service creates an additional operational dependency; local or cached decisions require explicit freshness and revocation rules.
Evaluate both arrangements against the same questions: where is the protected resource, who resolves its ownership, which component enforces the result, and what happens when that component can't obtain trustworthy policy context? Protocol familiarity is useful, but it shouldn't determine the trust boundary.
Authorization Patterns for RAG and Agent Workflows
For a multi-tenant support assistant, start with a reference flow in which the model proposes a retrieval request and a trusted service resolves its target. The service obtains a policy decision before releasing content to generation.
The diagram identifies the identities and context that the decision point must distinguish.
Resolve first, authorize next, deliver last
Tenant resolution must precede the resource decision. Don't accept a model-supplied tenant identifier as authoritative. Resolve the tenant from authenticated application context, then verify the requested object's ownership against canonical state.
Keep the end user, application service, and delegated agent identities distinct. Tenant membership is validated context, not another name for the requester; the delegation record should identify whose authority the agent exercises.
The resulting flow should be explicit:
- Resolve the target: Determine the tenant, object, and requested operation through trusted code.
- Evaluate authority: Submit the relevant principals and context to the policy decision point.
- Enforce at the resource: Permit only the operation described by the decision.
- Release authorized evidence: Pass approved content and provenance to generation.
- Validate delivery: Check that output claims have supporting evidence and that the destination is permitted.
This is an implementation pattern for enterprise RAG, not a claim that retrieval filtering alone establishes answer correctness. Authorized evidence can still be irrelevant or insufficient.
Keep a decision record that survives execution
A minimal retrieval-decision schema can be expressed without prescribing a storage format:
| Field Group | Required Contents |
|---|---|
| Request identity | Correlation ID, end-user principal, service principal, delegated agent |
| Target | Tenant, object identifier, requested action |
| Policy basis | Policy version, relevant context, decision timestamp |
| Outcome | Allow or deny, denial reason, validity constraints |
| Evidence | Authorized document identifiers and source versions |
| Execution | Retrieval result, tool result, delivery status |
Missing, stale, malformed, or unavailable policy context should produce denial or abstention, not a best-effort sensitive answer. Apply the same pattern to tool calls, with credentials scoped to the intended operation rather than the service's full capabilities.
The accompanying video offers another presentation format for examining the workflow.
For claim validation, retain the association between an output claim and its supporting evidence. Treat permission to retrieve, evidentiary support, and permission to deliver as separate checks. A correct answer sent to an unauthorized recipient is still an access-control failure.
Accounting as Evidence Reconstruction Not Session Counting
A session-start event proves that a session was recorded. It doesn't, by itself, establish which authority existed when an agent retrieved a document or executed an action.
Accounting should let an investigator reconstruct the decision state at the time of execution. That requires more than collecting additional application messages.
The investigation-oriented view is a timeline connecting identity, policy, evidence access, and execution.
Preserve the basis for authority
Use the decision schema above as the foundation, then preserve the context needed to interpret it later. That includes the relevant policy snapshot or reproducible version, delegated authority, retrieval authorization, evidence identifiers, denial reason, and actual result.
Cerbos's discussion of authorization blind spots auditors find provides a useful audit-oriented reference. The engineering requirement is specific: an investigator shouldn't have to apply today's policy to yesterday's action and assume it was identical.
The MIT accounting-integrity concerns around RADIUS include Message-Authenticator protection and client verification. Those concerns shouldn't be converted into an unqualified configuration rule for every RADIUS deployment; verify the applicable protocol and implementation requirements before changing accounting behavior.
Detect gaps and disagreement
An accounting pipeline needs checks for completeness and integrity, not just ingestion volume.
- Correlate transitions: Match policy decisions to retrieval, execution, and delivery events.
- Detect missing records: Flag execution without a corresponding decision or acknowledged accounting record.
- Control replay: Distinguish retries from new actions using request identity and explicit retry semantics.
- Preserve ordering evidence: Record clock context and event sequence information.
- Reconcile disagreement: Investigate conflicts among identity, policy, and application logs rather than choosing one alone.
These checks are proposed implementation controls, not demonstrated guarantees against forged records. Operators also need controlled write access and integrity verification appropriate to their logging infrastructure.
Audit test: Can an investigator explain why the action was permitted using preserved evidence, without trusting the generated answer?
For sensitive operations, define whether accounting must be durably acknowledged before execution. If required evidence can't be preserved, deny or restrict the operation according to an explicit failure policy.
That is the distinction between agentic AI observability and mere event collection: useful observation must connect behavior to the authority and evidence that justified it.
Session Lifetimes and Reauthentication for AI Actions
A long-running agent shouldn't inherit indefinite trust from an earlier human login. Authentication assurance includes time limits and renewed confirmation that the subscriber remains present.
NIST's limits differ by Authentication Assurance Level, and their normative language matters.
| Assurance Level | Overall Reauthentication Timeout | Inactivity Timeout |
|---|---|---|
| AAL1 | Should be no more than 30 days | No value cited here |
| AAL2 | Should be no more than 24 hours | Should be no more than 1 hour |
| AAL3 | Must be no more than 12 hours | Should be no more than 15 minutes |
These values come from NIST's Digital Identity Guidelines, which require periodic reauthentication and prohibit extending a session beyond its applicable limit using only the session secret. They are assurance-level guidance, not universal defaults for every AI application.
Translate assurance into credential boundaries
Select the appropriate assurance level based on the data, actors, and actions in scope. Then design tool and retrieval credentials so the agent can't outlive or exceed the authority from which they were derived.
- Credential scope: Restrict credentials to the intended resource and operation.
- Credential lifetime: Keep delegated access bounded by the relevant session and policy constraints.
- Sensitive actions: Require renewed authentication where the threat model calls for stronger assurance.
- Queued work: Validate current session and delegation state before execution.
Reauthentication and authorization solve different problems. Reauthentication establishes renewed confidence in the caller's identity; it doesn't restore a permission that an administrator revoked.
For suspected compromise, define the operational path from detection to session invalidation, delegated-credential revocation, and cancellation of pending work. Test that path with queued tool calls, not only interactive requests.
The resulting design keeps elapsed time from becoming an accidental permission grant. An agent's continued execution is a scheduling fact, not evidence that the human requester remains authenticated or authorized.
A Working Checklist and the Three Failure Modes to Engineer Against
Put these failure modes in the design-review template:
- Valid identity, forbidden resource: Use the negative tests in “Authorization as the Hard Problem in AI Stacks” to probe object, tenant, and delegation boundaries.
- Earlier permission, later execution: Apply “Session Lifetimes and Reauthentication for AI Actions” to queued work and revocation.
- Recorded activity, missing authority: Use “Accounting as Evidence Reconstruction Not Session Counting” to verify that preserved records explain the action.
Minimum review gates
Require an identified enforcement point for every sensitive retrieval and tool operation. Confirm that trusted code resolves resources, policy failures deny access, and generation receives only approved evidence.
Retain correlated decision and execution records, then test whether an investigator can reconstruct a representative action. Include denied operations and interrupted workflows, not just successful responses.
Assign owners for policy changes, credential revocation, evidence retention, and accounting failures. Set review cadence according to risk, and rerun boundary tests whenever resource models, delegation rules, or delivery destinations change.
A working AAA setup is demonstrated through enforceable decisions and inspectable records, not through the presence of a login screen.
AletheionAGI offers a grounding and evidence-control layer designed to work with existing LLMs, RAG pipelines, vector databases, and memory systems rather than replace them. Visit AletheionAGI to evaluate how its authorized retrieval, fail-closed grounding, and provenance controls could fit your application's policy enforcement and audit requirements.
