CapSeal: Capability-Sealed Secret Mediation for Secure Agent Execution

Abstract: Modern AI agents routinely depend on secrets such as API keys and SSH credentials, yet the dominant deployment model still exposes those secrets directly to the agent process through environment variables, local files, or forwarding sockets. This design fails against prompt injection, tool misuse, and model-controlled exfiltration because the agent can both use and reveal the same bearer credential. We present CapSeal, a capability-sealed secret mediation architecture that replaces direct secret access with constrained invocations through a local trusted broker. CapSeal combines capability issuance, schema-constrained HTTP execution, broker-executed SSH actions, anti-replay session binding, policy evaluation, and tamper-evident audit trails. We describe a Rust prototype integrated with an MCP-facing adapter, formulate conditional security goals for non-disclosure, constrained use, replay resistance, and auditability, and define an evaluation plan spanning prompt injection, tool misuse, and SSH abuse. The resulting system reframes secret handling for agentic systems from handing the model a key to granting the model a narrowly scoped, non-exportable action capability.

• The paper proposes CapSeal, a broker-mediated protocol that replaces static secret provisioning with session-bound, policy-narrowed capabilities to prevent key disclosure in AI agents.
• It demonstrates robust security via fine-grained policy evaluation, temporal binding, and tamper-evident audit logs, achieving zero credential leakage in experiments.
• The study confirms practical viability with minimal latency overhead, making CapSeal a promising framework for secure integration of AI agents with sensitive credentials.

CapSeal: Capability-Sealed Secret Mediation for Secure Agent Execution

Problem Motivation and Security Model

Autonomous AI agents, increasingly powered by LLMs and tool-integrated frameworks, must interact with sensitive credentials (API keys, SSH credentials, etc.) to operate in real-world environments. Conventional paradigms expose these secrets directly to the agent process—via environment variables, disk, or sockets—making them susceptible to prompt injection, tool misuse, and exfiltration if the agent's control or action space is compromised. This threat profile is intensified by agents’ dependence on dynamic toolchains and third-party extensions, automation of attack tactics, and the limitations of LLM-based review in adjudicating sophisticated, multi-stage adversarial control flow.

CapSeal formulates a rigorous adversary model wherein (a) attackers can fully steer agent prompts, retrieved context, and tool choices; (b) agent-side process memory and code paths are assumed untrusted, but the local broker, secret store, and OS process isolation remain trusted; and (c) local root compromise or hardware-level attacks are out of scope for v1.

Architecture and Protocol

CapSeal introduces a local, trusted broker architecture and security protocol that shifts from static credential provisioning to session-bound, policy-narrowed, non-exportable capabilities. Instead of direct key or credential access, the agent interacts with the broker via mediated requests describing “intents” coupled with precise scope constraints. The four architectural security goals realized are:

• G1: Secret Non-disclosure—agents never obtain secrets (or usable equivalents) under the TCB;
• G2: Fine-grained Policy Enforcement—all invocations are checked against multidimensional, declaratively enforced policies (host/path/command/restrictions, quotas, templates);
• G3: Temporal and Contextual Binding—strong anti-replay and channel-binding prevent authority reuse and session drifting;
• G4: Tamper-Evident Accountability—all protocol-relevant events are auditable in cryptographically protected, append-only logs.

This architecture creates a security boundary between agent-expressed high-level actions and their realization via credential mediation (Figure 1).

Figure 1: CapSeal architecture and trust boundary—agents submit intents and payloads; the broker mediates authority via session-bound, policy-checked execution and reference monitoring.

Protocol Design and Execution Lifecycle

The broker exposes a mediated RPC interface mapping tools or capability requests to a six-phase protocol: registration, capability request, policy evaluation, invocation, mediated execution, and audit export (Figure 2):

1. Session Registration: The agent registers a session, which is bound to OS-level process identity and authenticated transport (e.g., Unix domain sockets).
2. Capability Request: The agent specifies an intent and associated constraints (protocol, host, method, schema, etc.), which the broker considers for minimally scoped capability issuance.
3. Policy Evaluation: The broker, acting as PDP/PEP, evaluates requests against active policy, supporting step-up/multi-factor elevation where necessary.
4. Invocation: Invocations are bound to valid, non-expired handles, with strict anti-replay protocol (monotonic sequence numbers, nonces, TTL, quotas).
5. Mediated Execution: Typed executors (HTTP, SSH) enforce semantic constraints before credential injection and execution.
6. Audit Export: All actions, including denials and revocations, are immutably logged for verifiability and accountability.

   Figure 2: CapSeal request lifecycle from constrained capability issuance through broker-enforced execution and cryptographically protected audit export.

Typed Capability Realizations

CapSeal implements two capability types with progressively restrictive enforcement:

HTTP Capabilities

Broker-controlled HTTP capabilities transform HTTP actions into tightly scoped, schema-constrained RPCs. The agent cannot specify arbitrary destinations or use custom payloads; all parameters (method, host, path, schema) are validated, sensitive headers are sanitized, and payload shape is enforced via JSON Type Definition. Credential injection is performed server-side, and output redaction prevents leakage through responses.

SSH Capabilities

SSH mediation is broker-exec (as opposed to forwarding or signing oracle): the broker executes narrowly-constrained, template-bound SSH commands, with user/host/command argument and output size bounds, and cryptographic host key pinning. Agent forwarding and ambient session reuse are categorically denied, closing the door on classically unsafe SSH agent forwarding attacks.

Session and invocation control flows integrate multi-layered validation, ensuring each mediated action must pass all policy, replay, lifecycle, and executor checks (see Table 1 in the paper).

Implementation and Integration

The CapSeal prototype is implemented in Rust, including:

• Broker-core with session/capability tracking, anti-replay state, and handle lifecycle management.
• Typed executors for HTTP and SSH with fine-grained constraint logic.
• A policy subsystem supporting both local and remote (fail-closed) evaluation.
• Encrypted, pluggable secret and audit backends, maintaining compliance with cryptographically strong tamper-evident log chains.
• Agent-facing adapters bridging to MCP-style interfaces, enabling drop-in integration with contemporary agent toolchains while mediating all sensitive authority.

CapSeal is designed for modularity, supporting extensions to TEEs for broker hardening, integration into IoT/edge ecosystems for policy-enforced, device-scoped authority, and future MCP ecosystem extensions.

Empirical Evaluation

Three research questions structure the empirical study: credential leakage (RQ1), authority narrowing (RQ2), and operational overhead (RQ3).

• Key Leakage Prevention (RQ1): In both HTTP and SSH real-world end-to-end scenarios, direct-secret baselines yielded leakage rates of 1.000 (HTTP, B1/B2), but CapSeal prevented all credential disclosures (0.000, HTTP/SSH).
• Unauthorized Use Mitigation (RQ2): No system (B1, B2, CapSeal) allowed out-of-scope credential use in evaluated runs; CapSeal’s enforced binding closed ambient escalation paths even in steerable agent cases.
• Operational Overhead/Usability (RQ3): All systems, including CapSeal, preserved 100% benign request completion. Latency benchmarks (Figure 3) show CapSeal’s mediation overhead is minimal: for HTTP, median latency overhead is just 0.149 ms (lower than external mediation baselines), and for SSH, 0.208 ms, directly comparable to and lower than stateful runtime-shield approaches.

  Figure 4: CapSeal’s mediation achieves lowest latency among brokered enforcement designs for both HTTP and SSH, with minimal added overhead relative to direct execution.

Discussion, Limitations, and Implications

CapSeal’s model does not address local root compromise or hardware-level side-channels, positioning it as a system for strong but software-only adversary models (with the possibility of TEE extension). SSH mediation trades some compatibility for authority containment, requiring workflow adjustments where agent forwarding is standard. MCP integration and tool poisoning remain evolving targets for ongoing security research.

Practically, CapSeal provides a reproducible, auditable framework for controlling agent-side secret use by default, suitable for integration in high-assurance agent platforms, particularly where fine-grained audit, constrained delegation, and non-disclosure are critical.

Theoretically, CapSeal demonstrates that robust secret mediation is possible in steerable-agent architectures, reframing secret handling as a capability system problem, and concretizes how cryptographic policy enforcement, session binding, and semantic validation collectively bound agent privilege and exfiltration risk.

Future directions include TEE-backed brokers, hardware-bound key attestation, fleet-scale IoT deployments, and policy synthesis for arbitrary tool ecosystems. Further research can augment CapSeal with distributed audit anchoring, federated policy reasoning, and continuous robustness evaluation in the face of evolving agent supply chain and ecosystem attacks.

Conclusion

CapSeal formalizes and implements capability-sealed secret mediation for agentic systems, providing strong empirical evidence of key disclosure mitigation, policy-and-context scoped authority, low operational overhead, and cryptographically auditable histories. This paradigm is poised to inform the next generation of secure AI agent infrastructure where “grant an action” replaces “hand over a secret” as the principle of operation in secret management protocols.