Understanding shiftagent's Zero-Trust Security Model

Overview

shiftagent’s security architecture is built on a fundamental principle: the AI reasoning layer is an untrusted component. This document explains the technical mechanisms that enforce this principle at every layer of the platform.

The three security layers

Layer 1: Vault aliases

Every credential in the shiftagent platform is stored in a secrets vault (HashiCorp Vault or AWS Secrets Manager). The agent environment never contains real credentials — only aliases.

An alias is a human-readable reference like @stripe_api_key or @merchant_oauth_token. These aliases are meaningless outside the platform. Even if an attacker fully compromises the agent sandbox, they obtain only alias strings with no intrinsic value.

The mapping between aliases and real credentials is maintained exclusively in the vault, accessible only by the forward proxy service.

Layer 2: Forward proxy resolution

The forward proxy is the only component authorized to resolve vault aliases to real credentials. It operates as a network gateway between the agent sandbox and external services.

Request flow:

1. Agent constructs an API request using aliases: Authorization: Bearer @stripe_api_key
2. Request is routed to the forward proxy (direct internet access is blocked)
3. Proxy resolves @stripe_api_key from the vault
4. Proxy injects the real credential into the request headers
5. Proxy forwards the request to the destination (e.g., api.stripe.com)
6. Proxy receives the response
7. Proxy strips any real credentials that might appear in the response body
8. Proxy returns the sanitized response to the agent

Network isolation:

The agent sandbox has strict network controls:

• All outbound HTTP/HTTPS traffic must route through the proxy
• Direct internet access is blocked at the network level (iptables)
• Internal network ranges (RFC 1918, link-local, loopback) are blocked
• EC2/cloud metadata endpoints are blocked (prevents SSRF attacks)
• IPv6 private ranges are blocked

Layer 3: CIBA approval flow

For high-risk operations, credential resolution is gated behind human approval via CIBA (Client Initiated Backchannel Authentication).

Approval flow:

1. Agent requests a high-risk action (e.g., financial transaction)
2. GORules engine classifies the action’s risk level
3. If approval is required, the system initiates a CIBA flow
4. The human operator receives a push notification with action details
5. The operator approves or denies the action
6. If approved, the forward proxy resolves credentials and executes the request
7. If denied, the agent receives a denial response and can adjust its approach

Risk classification tiers:

Tier	Actions	Approval
0	Read data, generate reports	Autonomous
1	Send notifications, update records	Configurable
2	Financial transactions, credential access	Always required
3	Credential rotation, system configuration	Multi-party required

Multi-tier security inheritance

shiftagent’s multi-tenant architecture uses git branches as the tenancy model. Security policies follow the branch hierarchy:

• Platform level (main branch): Base security policies
• Partner level (e.g., payengine branch): Partner can tighten policies
• Tenant level (e.g., tenants/merchant-123): Tenant can tighten further

Critical rule: Each tier can only tighten the security posture of the tier above. A tenant cannot reduce approval requirements that the partner has set. A partner cannot reduce requirements that the platform has set.

Compliance implications

This architecture has direct implications for compliance frameworks:

PCI DSS: The agent layer is out of scope because it never handles real cardholder data or credentials. Only the forward proxy component requires PCI assessment.

SOC 2: The vault + proxy + CIBA pattern provides auditable access controls, least-privilege enforcement, and complete audit trails — satisfying Trust Service Criteria for security, availability, and confidentiality.

GDPR/CCPA: PII can be treated the same as credentials — stored in the vault, referenced by alias, resolved only by the proxy. The agent reasons about data without seeing the actual personal information.

Summary

shiftagent’s zero-trust security model ensures that:

1. The LLM never sees real credentials — only vault aliases
2. All outbound traffic is proxied — no direct internet access from agent sandboxes
3. High-risk actions require human approval — via CIBA push notifications
4. Security only tightens downstream — tenants inherit and can only strengthen partner policies
5. Compliance is architectural — PCI DSS scope is minimized by design, not by policy