SPIKE: Secrets Management

SPIKE is a SPIFFE-native secrets store built for zero-trust environments. It is an open-source project maintained at github.com/spiffe/spike. PRECINCT integrates SPIKE as its secrets management layer, providing automatic secret rotation and SPIFFE-authenticated access.

In agentic AI systems, the LLM is the credential consumer, and LLMs can be manipulated. SPIKE ensures that agents never see, hold, or transmit real credentials, eliminating an entire class of exfiltration attacks through late-binding secret substitution.

The Problem: Agents and Secrets

Traditional applications follow a simple pattern: the application receives a credential (API key, database password, OAuth token), stores it in memory, and uses it to authenticate against a downstream service. The application code is deterministic, reviewed, and trusted.

Agentic AI fundamentally breaks this model. The consumer of the credential is now an LLM (a probabilistic system that can be manipulated via prompt injection). If the LLM sees a real credential, the credential can be exfiltrated through any of several attack vectors:

Obfuscation: The LLM can split the credential character by character (s.k.-.a.b.c.1.2.3) and embed it in seemingly innocent output.
Chunking: The credential can be split across multiple requests, each fragment appearing harmless in isolation.
Encoding: Base64, ROT13, hex encoding, or any reversible transformation can disguise the credential in output text.
Steganography: The credential can be hidden in the structure of otherwise normal text, such as first letters of sentences, word spacing patterns, or Unicode homoglyphs.
Disk persistence: If the agent has file-write access, the credential can be written to a location accessible to the attacker.

The Core Insight

You cannot reliably detect credential exfiltration in LLM output. The space of possible encoding schemes is unbounded. The only reliable defense is to ensure the LLM never possesses the credential in the first place.

Late-Binding Secrets: The Solution

PRECINCT solves this through late-binding secret substitution. Instead of giving agents real credentials, agents operate with opaque, meaningless reference tokens. The gateway substitutes real credentials at the very last middleware step (step 13 of the 13-layer enforcement chain), immediately before the request leaves the gateway for the upstream service.

Agents never see real credentials. They work exclusively with opaque references like $SPIKE{ref:deadbeef}.
The gateway substitutes at the last step. Token substitution happens at step 13, after all inspection, policy evaluation, DLP scanning, and rate limiting have completed.
Even full middleware compromise is safe. If every middleware layer from step 0 through step 12 were compromised, the attacker would still only see the opaque reference, not the real credential.

How SPIKE Works

The following sequence shows the complete flow from agent request to upstream service invocation, illustrating how the real credential is never exposed to the agent or any middleware layer except the final substitution step.

sequenceDiagram participant Agent as AI Agent participant GW as Gateway participant MW as Middleware
Steps 0-12 participant SUB as Step 13:
Token Substitution participant SPIKE as SPIKE Nexus participant UP as Upstream Service Agent->>GW: Tool call with $SPIKE{ref:deadbeef} GW->>MW: Process through 12 middleware layers Note over MW: Size limit, body capture,
SPIFFE auth, audit log,
tool registry, OPA policy,
DLP scan, session context,
step-up gate, deep scan,
rate limit, circuit breaker MW->>SUB: Request passes all checks SUB->>SPIKE: Resolve ref:deadbeef
with agent SPIFFE ID SPIKE->>SPIKE: Validate identity +
token scope + TTL SPIKE-->>SUB: Return real credential SUB->>SUB: Substitute $SPIKE{ref:deadbeef}
with real credential SUB->>UP: Forward request with
real credential UP-->>GW: Response GW-->>Agent: Response (credential stripped) Note over Agent: Agent NEVER sees
the real credential

SPIKE Architecture

SPIKE consists of several components that work together to provide a secure, SPIFFE-native secrets management system.

SPIKE Nexus

The central secret store. Secrets are persisted in SQLite with AES-256-GCM encryption at rest. All access requires a valid SPIFFE identity, and every request is authorized against scope constraints (destination, TTL, allowed actions).

SPIKE Keeper(s)

High-availability key management via Shamir Secret Sharing. The master encryption key is sharded across multiple Keeper instances. A configurable threshold of Keepers must be available to reconstruct the key and unseal the Nexus.

SPIKE Bootstrap

A one-shot initialization container that generates the initial master key, shards it across Keepers, and configures the Nexus trust domain. Runs once during first deployment and exits.

SPIKE Secret Seeder

Provisions initial secrets into the Nexus during deployment. Reads secret definitions from configuration and creates the corresponding entries with scope bindings and TTL policies.

All Components Use SPIFFE

Every SPIKE component (Nexus, Keepers, Bootstrap, and Seeder) authenticates using SPIFFE/mTLS. There are no static credentials anywhere in the SPIKE infrastructure. Identity is attested, not configured.

Exfiltration Defense

Late-binding secrets defeat every known credential exfiltration vector because the agent never possesses the real value. The following table enumerates the attack vectors and explains why each fails.

Attack Vector	Example	Why It Fails
Obfuscation	`s.k.-.a.b.c.1.2.3`	Agent never has the real value to obfuscate. It can only split the opaque reference, which is useless.
Chunking	Send parts across multiple requests	The real value only exists at the egress boundary (step 13). There is nothing to chunk before that point.
Encoding	Base64, ROT13, hex	You cannot encode what you do not have. The agent sees only `$SPIKE{ref:deadbeef}`.
Steganography	Hide in normal text patterns	There is nothing to hide. The opaque reference carries no information about the real credential.
Disk persistence	Write credential to a file	Writing the opaque reference to disk is harmless. The reference is scoped, time-limited, and identity-bound.

Configuration

Configuring SPIKE involves three steps: establishing the trust domain, provisioning secrets, and binding token scopes.

Trust Domain Setup

SPIKE inherits its trust domain from SPIRE. All SPIKE components must be registered in the same SPIRE trust domain as the workloads they serve.

# spike-nexus configuration excerpt
trust_domain: "poc.local"
listen_address: "0.0.0.0:8553"
store:
  backend: sqlite
  encryption: aes-256-gcm
  path: /data/spike/secrets.db

Secret Provisioning via CLI

# Provision a secret into SPIKE Nexus
spike secret put \
  --name "groq-api-key" \
  --value "gsk_real_credential_here" \
  --ttl 3600 \
  --allowed-spiffe-ids "spiffe://poc.local/agents/*" \
  --allowed-destinations "api.groq.com"

# List all secrets (metadata only, not values)
spike secret list

# Generate an opaque reference token for an agent
spike token create \
  --secret "groq-api-key" \
  --spiffe-id "spiffe://poc.local/agents/mcp-client/dspy-researcher/dev" \
  --ttl 1800 \
  --action "read"

CLI distinction: The spike command is SPIKE's own CLI for direct secrets management. PRECINCT provides a separate agw CLI that wraps gateway, audit, compliance, and identity operations. See the CLI Reference for details on agw.

Token Scope Binding

Every opaque reference token is bound to three constraints:

Constraint	Description	Example
Destination	The upstream host(s) where the credential may be used	`api.groq.com`, `api.openai.com`
TTL	Maximum lifetime of the reference token	`1800` (30 minutes)
Action	The operations permitted with this token	`read`, `write`, `admin`

Scope Enforcement

If a token is presented for a destination or action not in its scope, SPIKE rejects the resolution request and the gateway returns a 403 Forbidden with a reason code. The rejection is logged in the audit trail with the requesting SPIFFE ID and the violated constraint.