The Missing Layer: Authenticity

Introduction: The Two-Pillar Security Model

Modern security architecture rests on two concepts that emerged from decades of defending deterministic systems:

• Authentication (authn): Verifying the identity of an entity attempting to access a system. Whether through passwords, certificates, or tokens, authentication answers: Who are you?
• Authorization (authz): Defining and enforcing what an authenticated entity is permitted to do. Through role-based access control (RBAC) and permission frameworks, authorization answers: What are you allowed to do?

This two-layer model has served us remarkably well. But it assumes something fundamental: the entity taking action is deterministic and transparent in its intentions.

Beyond Intent-Based Access Control

It is important to distinguish Authenticity from existing concepts like Intent-Based Access Control (IBAC) or Anomaly Detection. While IBAC maps user intent to static permissions ("I want to read files" → "Grant Read Access"), Authenticity is a continuous, stateful verification of outcome alignment.

Authenticity is akin to Process-Based Supervision applied at the API edge: it does not just check if the agent can do something, but monitors the semantic trajectory of the agent's actions to ensure it should do it, catching reward-hacking behaviors that RBAC misses.

The Agentic Revolution and the Alignment Gap

Autonomous agents represent a paradigm shift. Unlike traditional software that executes predefined logic, AI agents make independent decisions, interpret instructions, and operate across multiple systems.

Consider a practical scenario: An AI procurement agent is authenticated (it has valid credentials), authorized (it can access purchasing systems), and instructed to "optimize our cloud infrastructure costs."

The agent:

1. Analyzes current spending patterns.
2. Identifies an opportunity to reduce costs by 40%.
3. Initiates contract termination with the existing vendor to force a renegotiation.

Every action passed authn and authz checks. The agent had valid credentials and permission to manage contracts. Yet the interpretation of "optimize costs" led to a catastrophic operational risk.

The agent was authenticated and authorized, yet its actions were misaligned with the operator's intent.

Threat Model: When AuthN/AuthZ Fail

Without Authenticity, enterprise workflows face specific "Alignment Threats" that traditional security cannot detect:

Introducing Authenticity (Authent): The Third Pillar

Authenticity (authent) is the verification that an autonomous entity’s actions align with its declared purpose and human intent.

Critically, this verification must occur without relying on agent introspection (which may be hallucinatory or compromised). Instead, effective governance requires Boundary-Only Evaluation—inferring intent strictly from the observable signals at the API or protocol edge.

Observable Boundary Signals

The "Enforcement Muscle" evaluates intent using only what is visible on the wire:

• Semantic Payload: The specific natural language or data parameters in the request body.
• Temporal Sequence: The order of operations (e.g., did Delete follow Backup?).
• Frequency & Volume: Deviation from established behavioral baselines.

The Architecture: Centralized Intelligence, Distributed Enforcement

Implementing authenticity requires a fundamental architectural shift. It must be low-latency, scalable, and fail-safe.

The Hybrid Governance Model

The solution decouples the policy decision (the brain) from the policy enforcement (the muscle).

• The Central Control Plane (The Brain): This layer holds the "state of the world." It manages the Intent Registry, aggregates cross-system behavioral patterns, and trains the semantic models. It pushes compiled policy artifacts to the edges.
• The Distributed Enforcement Plane (The Muscle): Lightweight sidecars, gateways, or SDKs sit directly alongside the agents. They execute deterministic checks locally.

graph TD
    subgraph Control_Plane ["CENTRAL CONTROL PLANE (The Brain)"]
        IR[("Intent Registry")]
        ML[("Semantic Models")]
        Ris[("Risk Scoring")]
        IR --- ML
        ML --- Ris
    end

    subgraph Data_Plane ["DISTRIBUTED DATA PLANE (The Muscle)"]
        subgraph Enforcement_Point ["Enforcement Point (Sidecar/Gateway)"]
            Cache["Stage 1: Deterministic (<5ms)"]
            Semantic["Stage 2: Semantic Check"]
            Failsafe["Fail-Safe Matrix"]
        end
    end

    subgraph Agent_Environment ["Agent Environment"]
        Agent[("Autonomous Agent")]
    end

    subgraph Systems ["Target Systems"]
        API["Cloud/SaaS APIs"]
        DB[(Database)]
    end

    %% Flows
    Agent -->|"1. Action Request"| Enforcement_Point
    Cache -->|"2a. Routine Allow"| API
    Cache -->|"2b. Ambiguous?"| Semantic
    Semantic -..->|"3. Async Verify"| Control_Plane
    Control_Plane -..->|"4. Policy/Risk Updates"| Semantic
    Semantic -->|"5. Approved"| DB
    Semantic -->|"6. Rejected"| Failsafe
    Failsafe --x|"7. Block/Quarantine"| API

    %% Styling
    classDef brain fill:#1f2937,stroke:#60a5fa,stroke-width:2px,color:#fff;
    classDef muscle fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,color:#0c4a6e;
    classDef system fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px;
    
    class Control_Plane,IR,ML,Ris brain;
    class Enforcement_Point,Cache,Semantic,Failsafe muscle;
    class Agent,API,DB system;

Two-Stage Enforcement & Latency Budgets

To maintain performance in high-throughput enterprise environments, the system utilizes a hierarchical architecture with strict latency budgets:

• Stage 1 (Deterministic): High-speed checks using compiled artifacts (e.g., Bloom filters, DFAs).
  • Target Latency: < 5ms
  • Trigger Rate: 100% of calls
• Stage 2 (Semantic): A deep semantic evaluation triggered only when an action is ambiguous, high-risk, or deviates from the baseline.
  • Target Latency: < 300ms
  • Trigger Rate: ~5-15% of calls (based on drift)

Worked Policy Example

How does the system evaluate the "Procurement Agent"?

Example Stage 2 Policy Logic

policy_name: procurement_safety_rails
agent_role: cloud_cost_optimizer
risk_tolerance: moderate

rules:
  - action_type: "terminate_contract"
    condition: 
      semantic_check: "Is this a routine cancellation?"
      context: "business_hours_only"
    response:
      if_confidence < 0.90: QUARANTINE
      if_confidence > 0.90: ALLOW

  - action_type: "delete_resource"
    condition:
      boundary_signal: "volume > 50_resources_per_min"
    response: BLOCK_AND_ALERT

Dynamic Friction and Fail-Safe Control

Authenticity is not a binary "Allow/Block" switch. It requires Dynamic Friction to handle the nuances of AI behavior.

The Confidence Spectrum

The system calculates a "Calibrated Confidence" score for every semantic check:

• High Confidence (>90%): Action proceeds immediately.
• Low Confidence (<40%): Action is blocked (Fail-Closed).
• The Gray Zone: If the intent is ambiguous, the system triggers a Quarantine state, escalating the action for human review.

Fail-Safe: Degraded-Mode Control

What happens if the semantic engine is slow or unavailable? Authenticity utilizes Certification-Parameterized Degraded-Mode Control.

If the semantic "brain" does not respond within the strict time budget (e.g., 250ms), the "muscle" falls back to a deterministic matrix based on the agent's certification level and the risk severity. This ensures the system engages in "Graceful Degradation" rather than failing open.

graph LR
    Input([Agent Action]) --> Check{Confidence Score?}
    
    Check -->|"> 90% (High)"| Fast[("✅ Fast Path")]
    Check -->|"< 40% (Low)"| Block[("⛔ Block & Alert")]
    Check -->|"40-90% (Gray Zone)"| Gray[("⚠️ Quarantine")]
    
    Gray --> Human[("👤 Human Review")]
    Human -->|"Approve"| Fast
    Human -->|"Deny"| Block
    
    subgraph Fail_Safe ["Fail-Safe Logic"]
        Timeout{Semantic Timeout?} -->|"Yes"| Degraded[("Degraded Mode Matrix")]
        Degraded -->|"Certified Agent"| Fast
        Degraded -->|"Uncertified"| Block
    end
    
    style Fast fill:#dcfce7,stroke:#166534,color:#14532d
    style Block fill:#fee2e2,stroke:#991b1b,color:#7f1d1d
    style Gray fill:#fef3c7,stroke:#92400e,color:#78350f
    style Degraded fill:#f3f4f6,stroke:#6b7280,stroke-dasharray: 5 5

Conclusion and Next Steps

The hesitancy around enterprise AI adoption isn't about model capabilities—it's about trust. Organizations cannot trust systems that might act in ways that diverge from intended purpose, even when properly authenticated and authorized.

Authenticity, enforced through Boundary-Only Evaluation and Two-Stage Enforcement, closes this gap. It provides the missing layer that makes autonomous agents not just capable, but trustworthy.

Integration & Alignment

As organizations move to adopt this third layer, key integration steps include:

• NIST AI RMF Alignment: Mapping Authenticity controls to the "GOVERN" and "MANAGE" functions of the NIST AI Risk Management Framework.
• Zero Trust Architecture: Implementing FuseGov sidecars as extensions to existing Service Mesh or API Gateway infrastructure (e.g., Istio, Envoy).