Identity-Anchored AI Safety Protocol (IASP)

A Proposal for Context-Aware AI Authorization and Guardrail Evaluation

Author: Anh Nguyen
Organization: AI GRC Engineering, Repassure.ai
Status: Draft Engineering Proposal for Discussion
Version: 0.1 (July 2026)

Status

This document is a draft engineering proposal intended to stimulate discussion among AI platform providers, identity architects, AI governance practitioners, and enterprise security teams.

It is not a formal standard, Internet Draft, or IETF RFC.

The objective is to explore whether identity-aware authorization signals can complement existing content-based AI safety guardrails in enterprise security workflows.

Executive Summary

Current frontier AI models primarily enforce cyber safety by evaluating the content of user prompts.

This approach works well for many abuse scenarios.

However, cybersecurity introduces a unique challenge.

The same prompt that enables an attacker to develop an exploit may also enable an authorized incident responder to investigate an active breach.

From the model's perspective, the text may be nearly identical.

The authorization is not.

Recent public discussions surrounding the OpenAI–Hugging Face incident highlighted this operational tension. During incident response, security teams reportedly encountered situations where hosted AI safety guardrails restricted legitimate defensive workflows because the models lacked sufficient contextual information to distinguish authorized responders from potential attackers.

This proposal explores one possible architectural direction.

Rather than relying exclusively on prompt content, AI providers could incorporate cryptographically verifiable authorization assertions issued by trusted enterprise identity providers.

These assertions would not replace model safety mechanisms.

Instead, they would provide additional context that allows guardrail systems to evaluate both content and authorization before making safety decisions.

Motivation

Current AI safety systems generally evaluate:

• prompt content
• detected capabilities
• inferred risk

They generally have limited visibility into:

• organizational identity
• incident context
• authorization scope
• accountability
• audit trail

This creates an operational challenge for security teams.

During incident response, analysts may legitimately need AI assistance for:

• exploit reconstruction
• malware analysis
• forensic investigation
• vulnerability validation
• reverse engineering

Yet these requests often resemble offensive cyber activity when viewed purely as text.

IASP explores whether authorization context can become a first-class input to AI safety decisions.

Design Goals

IASP attempts to:

• Introduce identity-aware authorization into AI guardrail evaluation.
• Reuse existing enterprise identity standards wherever practical.
• Support least-privilege, time-bound authorization.
• Improve auditability of sensitive AI interactions.
• Reduce unnecessary defensive workflow interruptions.

Non-Goals

IASP is not intended to:

• eliminate malicious insiders
• replace model-level safety mechanisms
• guarantee that authorized users always have benign intent
• provide unrestricted access to frontier AI models
• bypass organizational governance processes

Instead, it seeks to supplement existing safety mechanisms with richer contextual signals.

Architectural Overview

IASP extends existing OAuth 2.0 / OpenID Connect identity workflows by allowing enterprise identity providers to issue short-lived authorization assertions that accompany AI API requests.

Rather than evaluating only:

Prompt

the guardrail evaluates:

Prompt

+

Verified Identity

+

Authorization Scope

+

Incident Context

The proposal intentionally builds upon mature identity technologies rather than defining an entirely new authentication ecosystem.

Core Components

The architecture introduces four primary actors:

Enterprise Identity Provider

Issues signed authorization assertions tied to approved security workflows.

Authorized Security Professional

Authenticated incident responder, SOC analyst, or approved researcher operating under organizational policy.

AI Provider Gateway

Validates token signatures, scopes, expiration, and trust relationships.

Context-Aware Guardrail Engine

Evaluates both prompt content and authorization metadata before determining the appropriate response.

Authorization Assertions

IASP proposes extending JWT claims with additional AI governance context.

Illustrative claims include:

• organization
• responder role
• engagement identifier
• incident ticket
• requested override scope
• expiration
• audit identifiers

The precise schema would require community review and is intentionally left open for refinement.

Decision Model

Instead of relying exclusively on content classification, the proposal introduces two dimensions:

Content Risk

• Low
• Medium
• High

Authorization Confidence

• None
• Verified
• Scoped
• Auditable

High-risk requests without authorization continue to receive standard safety responses.

High-risk requests accompanied by valid, scoped authorization may proceed under enhanced audit and policy controls.

The proposal therefore shifts the question from:

"Is this dangerous?"

to:

"Is this dangerous and appropriately authorized?"

Post-Hoc Accountability

IASP does not eliminate governance.

It moves part of governance from pre-execution blocking toward post-execution accountability.

Possible mechanisms include:

• immutable audit logging
• enterprise SIEM integration
• authorization traceability
• token revocation
• organizational oversight

Alternative Approaches Considered

IASP is not the only possible solution.

Other approaches include:

Manual human review

Simple but difficult to scale during active incidents.

Trusted researcher programs

Provide controlled access but may not operate at incident-response speed.

Local or self-hosted models

Avoid third-party guardrails but introduce infrastructure, operational, and governance considerations.

Static allow lists

Simple to implement but often lack contextual flexibility.

IASP differs by attempting to bring identity and authorization directly into guardrail evaluation while remaining compatible with existing enterprise identity infrastructure.

Open Questions

Several important design questions remain unresolved.

Trust Model

Who should be trusted to issue authorization assertions?

• Enterprise Identity Providers?
• Cloud providers?
• National CERTs?
• Accredited third parties?

Standardization

Should authorization scopes be provider-specific or standardized across AI providers?

Cross-Provider Trust

How should OpenAI trust an enterprise assertion issued through Microsoft Entra, Okta, or another identity provider?

Emergency Operations

How should incident-response authorization differ from routine security research?

Privacy

How much organizational context should be disclosed to AI providers?

Relationship to Existing Standards

IASP is intended to complement—not replace—existing standards such as:

• OAuth 2.0
• OpenID Connect
• JSON Web Tokens
• Zero Trust Architecture
• Enterprise Identity and Access Management

Rather than introducing a new identity ecosystem, the proposal explores how existing authentication and authorization mechanisms might be extended for AI safety workflows.

Invitation for Discussion

This proposal is deliberately published as an engineering discussion paper.

It is expected that many aspects—including trust relationships, authorization semantics, interoperability, and governance models—would evolve through collaboration with AI platform providers, enterprise identity experts, standards organizations, and the broader security community.

Constructive criticism is encouraged.

The goal is not to present a finished standard, but to begin a technical conversation about how AI safety systems might evolve beyond content-only evaluation toward richer, context-aware authorization models.