DOCS

How It Works

Understand SURADAR's five-layer authentication architecture for autonomous AI agents.

SURADAR authenticates and authorizes every action an autonomous agent takes. The system is organized into five layers, each addressing a distinct security concern.

The Five Layers

L1: Per-Request Auth

Every API call an agent makes passes through SURADAR’s authentication layer. Each request is individually verified against the agent’s credentials and the organization’s security policies. There is no implicit trust between requests.

L2: Session Identity

Agents maintain a continuous, verifiable identity across a session. SURADAR tracks the lifecycle of each agent session so that actions can be attributed to a specific agent instance, even when agents are running across distributed infrastructure.

L3: Action Binding

When an agent performs a high-stakes action (placing an order, modifying a record, transferring funds), SURADAR binds that action to the agent’s verified identity. This creates an immutable link between “who did it” and “what was done,” enabling audit and rollback.

L4: Agent Registry

Every agent in your organization is enrolled in a central registry with metadata including its purpose, owner, permissions, and trust level. The registry acts as the source of truth for which agents exist and what they are allowed to do.

L5: Governance

Organization-wide policies define what agents can and cannot do. Governance rules are evaluated in real time: rate limits, allowed actions, geographic restrictions, time-of-day constraints, and escalation requirements are all enforced before an action proceeds.

Request Flow

When an agent sends a request through SURADAR, the following sequence occurs:

  1. Identity resolved — The agent’s credentials are validated and its identity is established from the registry (L4).
  2. Session verified — The request is associated with an active, valid session (L2) and authenticated (L1).
  3. Policy evaluated — Governance rules (L5) are checked against the requested action. If the action violates policy, it is denied with a reason.
  4. Credential issued — A short-lived, scoped credential is issued for the downstream action.
  5. Action audited — The completed action is logged with its binding (L3), creating a full audit trail from agent identity to outcome.

The entire flow completes in milliseconds and requires no changes to the downstream services the agent calls.

Key Properties

  • Zero implicit trust — Every request is authenticated independently.
  • Full attribution — Every action traces back to a specific agent and session.
  • Real-time governance — Policies are enforced before actions execute, not after.
  • Infrastructure-agnostic — Works with any cloud, runtime, or orchestration framework.

Next Steps

← Previous Getting Started Next → Configuration