AI security: Identity and access control

In our first 3 articles, we framed AI security as protecting the system, not just the model, across confidentiality, integrity, and availability, and we showed why the traditional secure development lifecycle (SDLC) discipline still applies to modern AI deployments. We also focused on guardrails and different architectural approaches such as dual LLMs and CaMeL to help protect against prompt injection and unsafe actions.

This article completes the defense strategy by focusing on the backbone that makes guardrails enforceable in production—identity, authentication, authorization, and zero trust.

Guardrails reduce the likelihood of unsafe behavior, but identity and authorization limit the damage if something goes wrong. If an AI system runs with broad, always-on permissions, a clever prompt can turn "text" into "action." Strong identity access management (IAM) helps prevent that by making sure the system cannot execute privileged operations unless the right identity is proven and the right authorization is present.

Why identity becomes the backbone in agentic AI

When a large language model (LLM) can call tools, the highest-risk failures move from "bad outputs" to "unsafe operations." Tooling makes the consequences and impact real—data exposure, ticket modification, workflow execution, and automated actions can all occur downstream from a single manipulated interaction. 

This shifts the core question from, "Did the model follow policy?" to, "Did the system enforce the policy?" That enforcement is fundamentally an IAM problem:

• Who is requesting the action?
• What are they allowed to do?
• What context constraints must apply?
• Where is the decision enforced and audited?

The goal is to make sure the model is never the authority. The model can propose actions, but the system must verify identity and enforce authorization independently.

The identity model for AI systems: Who is acting?

AI systems are multi-actor systems. A single request often involves multiple identities that must remain distinct.

• End-user identity: The human initiating the request.
• Application identity: The service hosting orchestration and policy logic.
• Workload identity: Each component participating in the flow—retriever, policy gate, tool gateway, and model gateway.
• Tool identity: Downstream services being called, such as datastores, search, and workflow systems.
• Model invocation identity: Which model and which policy profile produced an output or tool plan.

Security failures often happen when identities merge into a single shared "agent credential." The safer pattern is explicit separation—authenticate each identity, scope each authorization decision, and make sure each step is attributable.

Authentication: Proving identities reliably

Authentication establishes who is acting at each step. In AI systems, you typically need the following 2 categories:

End-user authentication: User identity

For user identity, the key requirement is that downstream actions can be bound to a user session with clear provenance. This is the foundation for:

• Attributing actions to a real user.
• Enforcing user-scoped permissions.
• Auditing and investigating incidents.
• Preventing the agent from acting as an unbounded proxy.

Workload authentication: Service-to-service identity

Inside the platform, internal components must authenticate to each other without relying on static secrets. This is where SPIFFE/SPIRE becomes especially useful:

• Workloads receive cryptographic identities.
• Services authenticate to each other with mutual Transport Layer Security (mTLS).
• Identity becomes automatable, rotatable, and enforceable at runtime.

This fits naturally with the reality described in earlier articles—AI stacks are distributed systems with multiple layers like prompts, retrieval, tools, and infrastructure, so internal trust must be explicit, not assumed.

Authorization: Deciding what is allowed

Authorization determines the actions an authenticated identity is permitted to do, and under which constraints. In AI systems, authorization must be enforced to withstand prompt manipulation and model error.

Note the following critical rules:

• Authorization must not depend on the model’s interpretation of the request.
• Authorization must be enforced by deterministic system controls at trust boundaries.

A practical enforcement approach uses the following two complementary authorization checkpoints:

Orchestrator-side authorization: Pre-execution gating

Before any tool call is executed, the system evaluates:

1. Requested tool and operation type.
2. User identity and session properties.
3. Requested resource scope.
4. Data sensitivity classification.
5. Risk level of the operation.
6. Whether additional controls are required, such as confirmation, step-up authentication, and approvals.

This is where guardrails and IAM meet—the orchestrator applies policy to decide whether an action should even be attempted.

Tool/API-side authorization: Boundary enforcement

Even if the orchestrator is correct, the tool itself must enforce authorization independently. This prevents:

• Prompt injection from bypassing the orchestrator.
• Hallucinated tool calls from succeeding.
• Misconfiguration or policy drift at the orchestration layer.

This mirrors classic product security guidance: Never rely on caller intent—enforce policy at the boundary.

OAuth 2.1: Delegated access and scoped capabilities

OAuth 2.1 is the core building block for delegated authorization, especially when actions are taken on behalf of a user. The most important idea is not the protocol mechanics, it’s what OAuth enables architecturally:

• Scope-limited permissions: Tokens are constrained to specific capabilities.
• Short-lived access: Credentials expire quickly to reduce blast radius.
• Audience restriction: Tokens are intended for specific services, reducing reuse.
• User binding: Actions can be tied to a user identity and consent model.

In an AI tool ecosystem, OAuth helps avoid one of  the most dangerous anti-patterns—a single high-privilege agent credential that can do everything. With OAuth, each tool call is constrained by scopes that match the minimum required capability, and the downstream service can validate those scopes directly.

The key design idea here is that if an action truly represents a user’s authority, it should carry user-scoped authorization, not an unbounded "agent permission."

SPIFFE/SPIRE: Workload identity for zero trust internal systems

OAuth primarily covers user-delegated authorization patterns. SPIFFE/SPIRE focuses on workload identity inside your infrastructure, which is essential for a distributed AI stack.

SPIFFE/SPIRE supports:

• Strong service identities: Workloads receive verifiable identities.
• mTLS everywhere: Services authenticate each other cryptographically.
• Reduced secret sprawl: Less reliance on static API keys.
• Clear segmentation: Policies can specify which workloads may call which services.

This matters because modern AI systems are assembled from multiple cooperating services. Treating internal calls as trusted by default is fragile, especially when AI pipelines expand quickly and include many dependencies and integrations.

To quickly put SPIFFE/SPIRE into practice on Red Hat OpenShift, you can use Red Hat OpenShift zero trust workload identity manager to automate SPIRE deployment and lifecycle management while issuing short-lived, verifiable workload identities backed by attestation.

Zero trust for AI: The mindset that fits the threat model

Zero trust is a natural fit for AI systems because they continuously process untrusted inputs and are designed to generalize across contexts. The practical implications are straightforward:

• Assume inputs become adversarial over time: Users, documents, web content, retrieved context.
• Authenticate and authorize every access: Not just at the perimeter.
• Minimize implicit trust between internal services: Implement mTLS and workload identity.
• Continuously monitor for abuse patterns: Probing, automation signatures, policy boundary testing.

This is the "traditional security still applies" message in operational form—the AI layer adds new control surfaces such as prompts, retrieval, and tool plans, but the best defenses still come from explicit boundaries and enforceable policies.

You can learn more about zero trust in the article, The Red Hat OpenShift advantage: Zero trust and sovereignty for cloud-native and AI workloads.

Telemetry and auditability: Making enforcement measurable

If guardrails are only as good as your ability to measure them, IAM enforcement is only as good as your ability to attribute and audit it.

A production-grade AI system should generate auditable signals such as:

• Identity of the requester (user and workload).
• Tool requested, operation type, and parameters, with sensitive fields handled safely.
• Authorization decision and policy version.
• Allow/deny outcomes and reason categories.
• Rate limiting and anomaly signals.
• Correlation identifiers linking model output → tool plan → tool execution.

This is what makes security enforceable over time. Decisions become observable, comparable, and testable across deployments and policy changes.

How traditional product security still applies, and what becomes AI-specific

We have emphasized that AI extends SDLC rather than replacing it—datasets behave like build inputs, model artifacts behave like build outputs, and the system layer introduces new assets like prompts, retrieval corpora, and tool integrations.

From a product security perspective, the same disciplines remain essential:

• Threat modeling: Map trust boundaries across user input, retrieval, tools, and infrastructure.
• Secure development lifecycle (SDLC): Versioned policies, code review, secure defaults, and deployment gates.
• Secrets management: Eliminate secrets from prompts and logs, prefer short-lived credentials.
• Supply chain controls: Dependencies, models, and tooling are all part of the system risk.
• Monitoring and incident response: Detection, containment, rollback, revocation, and recovery.

The key update is that prompt, retrieval, and tool policies become first-class security artifacts, and IAM is what makes those policies enforceable in production.

Final thoughts 

Guardrails reduce the chance that an AI system behaves unsafely, but identity and authorization determine how much damage is possible when the system is manipulated, confused, or simply wrong.

A production design that reinforces security combines:

• OAuth 2.1 for scoped, delegated access tied to user identity.
• SPIFFE/SPIRE for strong workload identity and mTLS inside the platform.
• Twice-enforced authorization, first in the orchestrator as a pre-execution gate, and again at the tool boundary as an independent control. 

It also:

• Applies least privilege at the capability level with scoped permissions per tool, per operation, and per resource.
• Adopts zero trust defaults, by authenticating and authorizing every hop.
• Assumes inputs become adversarial over time.
• Makes controls measurable through audit trails, telemetry, regression tests, and runtime monitoring.

What have we learned?

The core message is consistent: AI security is not "model security," it is system security. Just as importantly, SDLC remains central. Prompts, retrieval configurations, tool integrations, policies, and guardrails are production artifacts that must be versioned, reviewed, tested, and deployed with the same rigor as code.

The new aspect of AI is that natural language, retrieved context, and tool plans are now part of the control surface. The not so new aspects are what makes defenses reliable—clear trust boundaries, least privilege, independent enforcement at execution points, and security controls that are measured, monitored, and improved over time.

Is your AI ready for production?

Create a no-cost Red Hat account to download our "Top considerations for building a production-ready AI environment" e-book and get 60-day self-service access to Red Hat product trials.