System Architecture & Trust Lineage

1. Architectural Philosophy

Traditional Identity and Access Management (IAM) systems operate on a static credential model:

User / Service ➔ Static API Key / OAuth Token ➔ Broad Access to System

In autonomous and multi-agent workflows, this paradigm fails. When AI agents act autonomously across multi-step chains:

1. **Authorization is lost downstream**: Downstream microservices only know who called them immediately (e.g., "Service A called Service B"), losing track of the initiating human, the acting agent, and the delegated purpose.

2. **Authority expands unchecked (Scope Creep)**: An agent authorized for Step 1 inadvertently triggers downstream automations for Steps 2, 3, and 4 under broad standing privileges.

3. **Revocation is disconnected**: Revoking an agent's entry credential does not cancel tasks already passed to downstream workers.

**Boundrix introduces Continuous Action Admissibility**:

*"Authority is not granted upfront as a static token; it is continuously evaluated at every execution boundary immediately before a consequential action occurs."*

2. Enforcement Boundaries: What Prevents the Agent from Bypassing Boundrix?

A primary question security buyers and enterprise CISOs ask is:

*"What prevents an autonomous agent from bypassing Boundrix and calling GitHub or downstream APIs directly?"*

Boundrix explicitly defines three deployment modes and enforcement boundaries:

Mode 1: SDK-Only Mode (Application-Level Intercept)

• **Mechanism**: The agent codebase or framework wrapper calls `client.authorize()` immediately before invoking any consequential tool.

• **Enforcement Boundary**: Application layer.

• **Customer Responsibility**: The customer remains responsible for ensuring that the agent process cannot bypass the SDK wrapper (e.g. via direct HTTP requests) within its runtime environment.

Mode 2: Sidecar / Tool-Gateway Mode (Network Isolation Proxy)

• **Mechanism**: The agent environment is sandboxed on the network layer and cannot directly reach external APIs (like GitHub or cloud endpoints). All outbound tool calls must pass through the local Boundrix sidecar or gateway proxy.

• **Enforcement Boundary**: Network boundary.

• **Guarantee**: The sidecar evaluates policies locally and forwards only verified `ALLOW` decisions to downstream targets. Unapproved calls are physically prevented from leaving the host network namespace.

Mode 3: Credential-Broker Mode (Zero Downstream Secrets)

• **Mechanism**: The agent execution environment is never provisioned with long-lived downstream credentials (such as GitHub PATs, database credentials, or AWS keys).

• **Enforcement Boundary**: Cryptographic credential boundary.

• **Guarantee**: Boundrix or the customer-side gateway mints, injects, or signs narrowly scoped, short-lived tokens only after authorization succeeds. Direct unbrokered API calls by an agent are rejected by downstream services due to lack of valid credentials.

**Architecture Note**: We never claim "bypass is impossible" in SDK-only mode. Hard anti-bypass guarantees require either Network Isolation (Sidecar/Gateway) or Cryptographic Isolation (Credential Broker).

3. Multi-Hop Trust Chain Lineage

Every action request carries verifiable origin intent across the entire delegation chain:

┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ Initiating User │ ───►  │ AI Agent (NHI)  │ ───►  │  Task & Scope   │ ───►  │ Execution Target│
│  (Principal)    │       │   (Actor ID)    │       │    (Intent)     │       │ (GitHub / API)  │
└─────────────────┘       └─────────────────┘       └─────────────────┘       └─────────────────┘
         │                         │                         │                         │
         └─────────────────────────┼─────────────────────────┴─────────────────────────┘
                                   ▼
                   ┌───────────────────────────────┐
                   │    Boundrix Decision Point    │
                   │      (POST /authorize)        │
                   └───────────────┬───────────────┘
                                   │
                     ALLOW / DENY / REQUIRE_APPROVAL
                                   │
                                   ▼
                   ┌───────────────────────────────┐
                   │   Immutable Audit Evidence    │
                   └───────────────────────────────┘

Context Transferred Across the Chain:

• **Origin Identity**: Initiating human principal (`user-swati-dev`) for downstream human accountability.

• **Agent Identity**: Acting Non-Human Identity (`agent_id`, `tenant_id`) with strict lifecycle states (`ACTIVE` / `REVOKED`).

• **Delegated Scope**: Scoped `Task` (`repo`, `branch`, `allowed_actions`) preventing scope expansion.

• **Runtime Context**: IP, timestamp, resource attributes, and caller intent preventing stale replay attacks.

4. Latency Budget (< 1ms Decision Overhead)

In an autonomous agent execution step, **>99.8% of time is spent on LLM reasoning and downstream API operations**:

**Net Performance Impact**: Adding ~1ms of authorization check to a 3,500ms agent execution turn represents a **0.03% overhead**, which is completely imperceptible.