Paper deep dive
CapSeal: Capability-Sealed Secret Mediation for Secure Agent Execution
Shutong Jin, Ruiyi Guo, Ray C. C. Cheung
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 97%
Last extracted: 4/27/2026, 1:40:31 AM
Summary
CapSeal is a capability-sealed secret mediation architecture designed to secure AI agents by replacing direct access to secrets (like API keys and SSH credentials) with constrained, broker-mediated invocations. Instead of the agent possessing a bearer token, it requests a session-bound, narrowly scoped 'capability' from a local trusted broker. The architecture uses a Rust-based prototype with an MCP-facing adapter to enforce security goals such as non-disclosure, fine-grained policy enforcement, anti-replay resistance, and tamper-evident auditing. It features two specific realizations: a schema-constrained HTTP executor and a broker-executed SSH command executor, ensuring that even if an agent is compromised via prompt injection or tool misuse, it cannot exfiltrate the underlying secrets.
Entities (7)
Relation Signals (5)
CapSeal â integrateswith â Model Context Protocol (MCP)
confidence 100% ¡ CapSeal leverages this protocol to formalize the interface between the agentâs intent and the brokerâs enforcement.
Local Trusted Broker â mediates â HTTP Capability
confidence 100% ¡ The broker... validates the body against the declared schema reference [for HTTP].
Local Trusted Broker â mediates â SSH Capability
confidence 100% ¡ The SSH executor performs cryptographic host key verification... [within the broker].
Prompt Injection â targets â AI Agents
confidence 100% ¡ The current landscape is fraught with emerging threats specifically targeting agentic logic... Notable among these are: Prompt Injection.
CapSeal â uses â Local Trusted Broker
confidence 100% ¡ CapSeal... replaces direct secret access with constrained invocations through a local trusted broker.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2604.16762v1
- Canonical: https://arxiv.org/abs/2604.16762v1
Trouble viewing inline? Open PDF directly â
Full Text
52,029 characters extracted from source content.
Expand or collapse full text
CapSeal: Capability-Sealed Secret Mediation for Secure Agent Execution Shutong Jin 1 , Ruiyi Guo 2 , and Ray C. C. Cheung 1 1 City University of Hong Kong, Hong Kong 2 Beijing Foreign Studies University 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 au- dit 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 âhand the model a keyâ to âgrant the model a narrowly scoped, non-exportable action capability.â I. INTRODUCTION The integration of autonomous AI agents has catalyzed a paradigm shift in software development and production, of- fering unprecedented gains in efficiency and task automation. However, this rapid adoption has outpaced the evolution of security frameworks. Traditional defensive measuresâsuch as static encryption and digital signatures designed for human- mediated workflowsâare increasingly inadequate in an era of agentic autonomy. As agents transition from passive assistants to active decision-makers with access to sensitive environ- ments, the attack surface has expanded in both complexity and scale. The current landscape is fraught with emerging threats specifically targeting agentic logic and integrations. Notable among these are: ⢠Prompt Injection: Exploiting Large Language Model (LLM) vulnerabilities to hijack agent intent [1], [2]. ⢠Skill Poisoning: Corrupting the functional capabilities or âskillsâ an agent retrieves to perform tasks [3], [4]. ⢠MCP (Model Context Protocol) Poisoning: Injecting malicious context or instructions through standardized communication protocols [5], [6]. ⢠Supply Chain Attacks: Compromising the external li- braries and toolkits that agents rely upon [7], [8]. We posit that the risks inherent in the agent era are sig- nificantly more severe than those of the preceding pre-agent era for three primary reasons. First, agents rely heavily on dynamic, online toolkits and third-party sources, increasing exposure to external vulnerabilities. Second, the democratiza- tion of cyberattacks means that adversaries are now utilizing coding agents themselves to automate vulnerability discovery and exploit generation, making the execution of attacks far more accessible. Finally, the growing reliance on LLM-based code review cannot be fully trusted, as these models often fail to detect sophisticated, multi-step adversarial logic. Recent real-world evidence, such as the supply chain compromises in axios and liteLLM, alongside skill poisoning instances in Clawhub, demonstrate that attackers are advancing at the same velocity as the developers building these agentic systems. The core motivation of this research is that agent-targeting attacks cannot be effectively mitigated through traditional means, as the attack-and-defense warfare is growing rapidly alongside AI capabilities. We therefore approach this problem from a cryptographical perspective: can we protect an agentâs most valuable data by default? While standard at-rest encryption provides a baseline of safety, it is insufficient for autonomous systems. In an agentic workflow, the agent must frequently utilize these secrets to au- thorize transactions, generate signatures, or access functional APIs. Consequently, the moment of greatest vulnerability is during use-time. To bridge this gap, this paper presents CapSeal, a capability-sealed secret mediation architecture that addresses this use-time exposure by replacing direct credential ac- cess with constrained, broker-mediated invocations. The agent never obtains the secret itself; instead, it requests a session- bound handle for a specific, policy-evaluated intent, and a local trusted broker mediates all credential-bearing actions through typed execution paths. The broker enforces schema constraints, redacts outputs, tracks anti-replay state, and records decisions in a tamper-evident audit chain [9]. This paper makes four contributions. ⢠We articulate the use-time secret exposure problem for agent systems and argue that direct secret mounting is incompatible with prompt-robust agent execution. ⢠We present CapSeal, a capability-sealed mediation ar- chitecture for session establishment, capability issuance, invocation, revocation, and audit proof export. ⢠We design two concrete capability realizations: schema- confined HTTP execution with credential injection and broker-executed SSH commands with host and command- template constraints. arXiv:2604.16762v1 [cs.CR] 18 Apr 2026 ⢠We define a reproducible evaluation methodology across benign tasks, prompt injection, tool misuse, and SSH abuse, with MCP tool poisoning isolated as an explicit extension experiment. In addition, we provide a same-harness latency comparison against direct execution and two external mediation baselines, allowing CapSealâs runtime cost to be assessed under identical HTTP and SSH tasks. I. BACKGROUND AND THREAT MODEL A. Why direct secrets fail in agent systems Bearer credentials are unsafe when handed to a component that is both semantically steerable and externally connected. RFC 6750 explicitly warns that a bearer token grants access to any party that possesses it [10]. In agent systems, possession is not limited to memory reads: a prompted model can trans- form, summarize, paraphrase, or exfiltrate the same credential through tool parameters, logs, or follow-on instructions [11]. This risk is amplified by the agent tool plane. MCP and similar frameworks standardize tool discovery and invocation, which improves developer ergonomics but also expands the attack surface to tool descriptions, tool-choice prompts, and output handling [12]. Consequently, the system must defend not only against a malicious final tool invocation, but also against earlier steering that changes what tool the model chooses to call [13], [14]. B. Adversary and trust assumptions CapSeal adopts a deliberately conditional threat model. Adversary capabilities. ⢠The adversary can influence agent prompts, retrieved context, or tool descriptions [15], [16]. ⢠The adversary can cause the agent to request capabilities or submit crafted invocation payloads. ⢠The adversary may control remote services or network paths outside the local broker boundary. Trusted computing base. ⢠The local broker, policy engine, secret store, and audit subsystem form the minimal TCB [17], [18]. ⢠The operating system correctly enforces local process isolation and Unix-domain-socket peer identity. ⢠The adversary does not have local root or kernel com- promise in the v1 model. Out of scope. ⢠Memory scraping or binary replacement by a local root adversary. ⢠Side channels below the abstraction level of broker- visible protocol events. ⢠Cross-host broker federation, multi-tenant isolation, and hardware-bound attestation. I. CAPSEAL ARCHITECTURE AND PROTOCOL The design of CapSeal is governed by four primary security objectives, which define the trust boundaries between the agent, the broker, and external services. Trusted Computing Base (TCB) Untrusted Zone Agent Runtime LLM / tools / prompt injection Broker (PEP / Capability Mediator) Capability Manager session-bound handle, expiry, quota Invocation Handler input validation, command shaping Policy Engine (PDP) allow/deny, scope check, host & user constraints Execution Layer HTTP Executor allow-listed endpoints, methods, timeouts SSH Executor host/user/command constraints, restricted signing (ssh-agent/HSM) Secret Store (Encrypted at Rest) API keys SSH private keys Audit Log (Append-only, Hash-Chained) Remote HTTP Services Remote SSH Targets UDS / JSON-RPC control / policy uses secret X No Direct Secret Access All secret usage is mediated via the Broker Fig. 1. CapSeal architecture and trust boundary. The broker acts as a reference monitor; agents submit intents and payloads, while the broker manages secret injection and execution. G1: Secret Non-disclosure. Under our established trust assumptions, the agent must never obtain the secret plaintext or any functional equivalent (e.g., replayable session tokens or raw private keys). The architecture ensures that secrets are only materialized within the brokerâs isolated execution context. G2: Fine-grained Policy Enforcement. Every invocation must satisfy a multi-dimensional constraint check. The broker enforces least-privilege access by validating requests against issued capability specifications, including destination host/path restrictions, command templates, rate-limiting quotas, and mandatory step-up authentication. G3: Temporal and Contextual Binding. To prevent cre- dential hijacking, invocation messages must be resistant to replay attacks and context mis-binding. Capabilities are bound to specific sessions and channels, utilizing anti-replay state to ensure that captured traffic cannot be reused across different temporal or logical contexts. G4: Tamper-Evident Accountability. Every security- relevant eventâincluding issuance, invocation, and revoca- tionâis recorded in an append-only, integrity-protected struc- ture. This allows for asynchronous consistency checking and provides a verifiable audit trail [19], [9]. Critically, CapSealâs guarantees are stronger than simple âat-restâ encryption but narrower than a full hardware-root- of-trust (absent TEE extensions). We assume a boundary where an agent, while potentially malicious or compromised, is logically isolated such that it cannot exfiltrate secrets and can only trigger actions explicitly authorized by the broker. As illustrated in Figure 1, the CapSeal architecture centers on a fundamental decoupling: the agent expresses intent, but only the broker performs execution. This separation transforms the broker into a formal Policy Enforcement Point (PEP) and Policy Decision Point (PDP). The agent is restricted to re- questing capabilities and submitting payloads for redaction or processing, while the secret material remains strictly confined to the broker-side execution path. A. Architectural Components The CapSeal control plane is structured as a mediated pipeline. Rather than providing a flat set of tools, the system enforces a strict state machine: a client must first establish a secure session, obtain a narrowly-scoped capability handle through policy approval, and only then proceed to invocation. This architecture ensures that protocol messages serve as sequential security gates rather than simple API endpoints. B. Request Lifecycle and Protocol Flow The execution lifecycle begins with the agent interacting with an MCP-compatible runtime. To the agent, the system appears as a set of standard tools; however, these tools are mediated by a CapSeal adapter. As shown in Table I, the current prototype maps high-level MCP verbs to low-level broker operations implemented in Rust. The adapter facilitates communication via JSON-RPC over Unix Domain Sockets (UDS), maintaining a clean separation between the agentâs high-level tool use and the brokerâs rigorous session manage- ment. The CapSeal protocol processes each request through six distinct stages: 1) Registration: The register operation establishes a session context, binding subsequent actions to a verified transport identity. 2) Capability Request: The req_cap operation declares an intent, specifying the required capability type and as- sociated scope constraints (e.g., allowed hosts or paths). 3) Policy Evaluation: The PDP evaluates the request against active security policies, determining if the au- thority should be granted, denied, or require multi-factor âstep-upâ approval. 4) Invocation: The agent uses the issued handle via invoke, providing necessary payloads and anti-replay metadata. 5) Mediated Execution: The broker validates the invo- cation against session state and capability constraints, injects the required secrets, and executes the action on the agentâs behalf. 6) Audit Export: Finally, audit.prove generates cryp- tographic evidence of the transaction for the append-only ledger. The scope field within a capability is the primary mecha- nism for authority narrowing. By restricting parametersâsuch as pinning an HTTP request to a specific POST method on api.example.com and validating the payload against a JSON Type Definition schema [20]âthe broker ensures the agent cannot deviate from the pre-authorized intent. If an agent attempts to manipulate the destination or the payload structure, the broker terminates the request before the secret is ever exposed to the network stack. TABLE I PROTOCOL OPERATIONS, SECURITY PURPOSE, AND PRIMARY ENFORCEMENT CHECKS. OperationSecurity PurposePrimaryEnforcement Checks registerSession Establishment Transport binding, peer-cred verification req_capAuthority GrantingPolicy match, intent parsing, step-up requirements invokeMediated ExecutionSession validity, anti-replay, TTL, quota, scope valida- tion revokeAuthority RescissionStateupdate,immediate handle invalidation audit.prove AccountabilityConsistency proof genera- tion, chain verification C. Session Binding and Replay Resistance To satisfy goals G2 and G3, CapSeal implements strict session binding. The broker utilizes UDS peer-credential ex- traction to identify the calling process, preventing identity self-assertion. A capability handle is cryptographically useless outside the specific channel and session for which it was generated. Replay protection is enforced through an AntiReplay structure containing a monotonically increasing sequence number, a unique nonce, and a millisecond-precision times- tamp. An invocation is only accepted if it satisfies four concurrent conditions: (i) it is bound to an active session, (i) it references a valid, non-expired handle, (i) it passes freshness and nonce-tracking checks, and (iv) it falls within the allotted call quota. This multi-layered validation ensures that authority remains a transient, context-bound privilege rather than a reusable credential. IV. CAPABILITY REALIZATIONS A. HTTP capability The HTTP capability is designed to behave as a constrained request constructor rather than a general-purpose forward proxy. That distinction matters because a generic proxy would still hand the agent broad routing power, making it easy to redirect requests, reshape payloads, or smuggle credentials through loosely checked parameters. CapSeal instead treats an HTTP capability as pre-authorized authority over a narrow method/host/path surface whose request body can itself be semantically confined. The following example illustrates how an agent requests a capability for calling an OpenAI-like API. The request declares the agentâs intent (http_call_openai_like), specifies the credential resource (OPENAI_API_KEY), and defines narrow scope constraints that the broker will enforce during invocation. The narrowing path is layered. The broker first validates method, host, and path against the issued scope, then enforces payload-byte limits and header allowlists, rejects sensitive caller-supplied authorization headers, and injects the credential UntrustedTrusted Computing Base (TCB) AgentBrokerPolicy EngineExecution LayerAudit LogRemote Service Phase I: Authorization Phase I: Capability Invocation (...) Broker is the sole ingress across the trust boundary. Phase I: Trusted Execution and Auditing (1) Request(op, args) (2) Policy query (3) Decision + constraints (6) Append request metadata (5) Invoke(handle, req) (7) Dispatch authorized operation (8) Resolve bound credential (9) Non-exportable use context (11) Return raw status (12) Append result digest ExternalRemote Service Secrets remain non-exportable. Only derived use is permitted. (13) Return sanitized result Fig. 2. CapSeal request lifecycle from capability request to broker-mediated execution and audit proof export. Fig. 3. Capability request for schema-constrained HTTP action. "jsonrpc": "2.0", "id": "2", "method": "capseal.req_cap", "params": "session_id": "sess_4d7f", "intent": "http_call_openai_like ", "cap_type": "HTTP_PROXY", "resource": "secret_id": "OPENAI_API_KEY" , "scope": "method": ["POST"], "host": "api.example.com", "path_template": "/v1/chat/completions ", "body_schema_ref": "jtd: ChatCompletionRequest.v1" internally. Only after those network-level checks pass does it validate the body against the declared schema reference. Schema validation operates on typed request definitions, ensur- ing that the request body conforms to the permitted structure. This is the point where CapSeal moves beyond simple network mediation into semantic mediation: the agent is not merely restricted to a destination, but to a permitted request shape. The HTTP executor enforces these constraints through pro- gressive validation. The system first validates network-level restrictions (method, host, path), then enforces payload size limits and header policies, sanitizes credentials in responses, and injects authentication tokens internally. Schema validation failures result in denial before any credential use, ensuring fail-closed behavior. The broker mediates communication with external endpoints, treating unreachable or unauthorized desti- nations as constraint violations that trigger denial. When audit evidence generation is enabled, the broker records request-side artifactsârequest structure, policy decisions, and response metadataâwithout exposing the underlying credential to the agent. This ensures that even if policy permits a capability, the executor prevents misuse through type-specific validation. B. SSH capability SSH uses a stricter realization because the threat surface is stronger. If CapSeal merely forwarded an SSH agent or exposed a reusable signing interface, the agent would still hold a powerful ambient channel whose misuse is hard to bound. For that reason, CapSeal adopts a broker-exec model: the broker executes a narrowly constrained remote action, and the agent never directly holds SSH secret material or a forwarding- capable socket [21], [22]. The following request is the exact SSH capability issuance shape used by the MCP adapter in our real Docker end-to-end experiment trace. The enforcement path again narrows authority step by step. The capability first constrains the remote host and user, then restricts execution to an approved command-prefix template with bounded arguments, forbids forwarding, and caps output size. The culminating control is host authenticity: the execu- tor compares the presented host key against the capabilityâs known_hosts_pin. That final comparison is what prevents a session from remaining valid if the agent is redirected to a different SSH endpoint that happens to fit the same superficial hostname or command shape. Fig. 4.SSH capability request from real MCP end-to-end experiment transcript. "jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": "name": "capseal.req_cap", "arguments": "intent": "ssh_mcp_e2e", "cap_type": "SshExec", "resource": "secret_id": "SSH_PROD_KEY" , "scope": "Ssh": "host": "sshd", "user": "capseal", "command_prefix": [ "ssh", "-i" ], "max_arguments": 3, "known_hosts_pin": "ssh-ed25519" "max_output_bytes": 2048 , "step_up": "None" The SSH executor enforces these constraints through a progressive validation sequence. The system verifies host and user allowlists, validates command invocations against approved templates, limits argument counts, prohibits agent forwarding, and bounds output sizes. Critically, the executor performs cryptographic host key verification, comparing the presented host identity against the pinned key specified in the capability. This cryptographic binding prevents capability misuse even if an adversary controls a host matching the requested hostname or command pattern. The architecture deliberately adopts broker-exec over signing-oracle delegation because the latterâs security depends on forwarding constraints that are difficult to enforce statefully and provide weaker isolation than direct broker mediation. C. Invocation Control Flow Regardless of capability type, every invocation follows a defense-in-depth validation sequence before the broker allows secret-bearing execution. The following logic illustrates the ordered checks that enforce session binding, anti-replay guar- antees, quota limits, policy decisions, and type-specific execu- tor constraints. This validation sequence realizes a defense-in- depth architecture where multiple independent security layers collectively ensure safe credential use. Session and capability lookups provide contextual validity. Replay detection through monotonic sequence numbers, unique nonces, and timestamp bounds prevents reuse attacks. Revocation, expiry, and quota checks enforce temporal and usage constraints. Policy evalu- ation enables runtime authorization decisions that can adapt to threat context. Executor constraint validation enforces the type-specific narrowing rules described aboveâHTTP schema validation or SSH command-template enforcement. Only when all checks pass does the broker inject credentials and perform the action, followed by an immutable audit log entry [9]. This layered design ensures that compromising a single validation layer does not grant the adversary access to credentials or un- restricted capability useâeach layer provides an independent security barrier that must be satisfied before secret-bearing execution occurs. V. INTEGRATION AND EXTENSION To demonstrate the versatility and robustness of the CapSeal framework, we explore its integration with emerging industry standards, hardware-level security primitives, and diverse de- ployment scenarios. This section details how CapSeal extends its capability-based mediation to the Model Context Protocol (MCP), Trusted Execution Environments (TEE), and Internet of Things (IoT) ecosystems. A. Standardizing Agent-Tool Interaction via MCP The Model Context Protocol (MCP) has emerged as a stan- dard boundary for decoupling agent runtimes from external toolsets. CapSeal leverages this protocol to formalize the inter- face between the agentâs intent and the brokerâs enforcement. By adopting MCP, CapSeal effectively separates the request for action from the secret-bearing execution, ensuring that agents interact with a familiar, high-level protocol surface rather than handling low-level, sensitive credentials. This integration enables CapSeal to be seamlessly plugged into mainstream agent toolchains. Instead of receiving raw, reusable API keys, the agent invokes approved actions through a standardized MCP layer. This layer acts as a specialized adapter that translates protocol-compliant requests into internal CapSeal capability operations. Crucially, while the MCP layer facilitates interoperability at the edge, the CapSeal broker maintains its role as the ultimate policy and execution au- thority, keeping security-critical decisions isolated from the agentâs immediate environment. B. Hardening the Broker with Trusted Execution Environments (TEE) While CapSeal provides logical isolation, the broker itself remains a high-value target. To mitigate the risk of host- level software compromise, we extend CapSeal with sup- port for Trusted Execution Environments (TEEs). By utilizing hardware-enforced isolation and remote attestation, we move sensitive security logicâsuch as key management and policy evaluationâinto a protected enclave. Integrating TEEs into the CapSeal architecture significantly raises the assurance level of the system. Specifically, the brokerâs secret-handling routines and session-control logic are executed within an attested TEE boundary, shielding TABLE I AUTHORITY NARROWING MECHANISMS IN CAPSEAL. Capability areaAuthority sourceEnforcement pointEnforcement mechanisms Transport/sessionSession-bound capability han- dle UDS transport and broker session state Peer credential binding, anti-replay validation (monotonic sequence, nonce uniqueness, times- tamp bounds), TTL/quota/revocation checks HTTPBroker-held API credentialHTTP executorNetwork-level restrictions (method, host, path), payload size limits, header policies, creden- tial injection, schema validation, audit evidence generation SSHBroker-held SSH materialSSH executorHost/user allowlists, command template valida- tion, argument limits, agent forwarding prohi- bition, output bounds, cryptographic host key verification PolicyContextual authorization deci- sion Policy engineRuntime policy evaluation, allow/deny/step-up decisions, auditable policy trace AuditAppend-only evidence chainAudit and secret subsystemsCryptographic audit chain, optional crypto- graphic signing, encrypted secret storage them from potentially compromised operating systems or hypervisors. This âhardware-root-of-trustâ approach reinforces the integrity of the broker without necessitating changes to the existing capability protocol or the developer workflow. From the agentâs perspective, the transition to a TEE-backed broker is transparent, yet the underlying protection against lateral movement and memory introspection is substantially strengthened. C. Extending Mediation to IoT and Edge Computing The challenges of Internet of Things (IoT) and edge deploymentsâcharacterized by heterogeneous hardware, in- termittent connectivity, and the need for device-scoped authorityâalign closely with CapSealâs design philosophy. In these settings, the risk of physical device compromise necessitates a transition away from long-lived, broad-scope credentials toward narrow, auditable control over secret use. CapSeal adapts to IoT environments by functioning as a dis- tributed mediation layer. In this model, each edge node or IoT device is granted highly constrained capabilities rather than direct access to central secrets. This architecture minimizes the blast radius of a single node compromise; an attacker gaining control of a device is limited to the specific, pre- authorized actions defined by its active capabilities. Further- more, CapSealâs centralized audit and revocation mechanisms allow administrators to manage fleet behavior in real-time, providing a scalable framework for orchestrating complex, secure operations in distributed physical settings. VI. PROTOTYPE IMPLEMENTATION We realize the capability-mediated architecture as a broker- centered system with integrated evaluation infrastructure. The implementation demonstrates the full security lifecycle: session-aware capability issuance, typed executor enforcement, policy-mediated approval, secret confinement within the bro- ker boundary, and auditable evidence export. This end-to-end realization is essential because the security guarantees depend on the coordinated interaction among these components rather than on any individual mechanism in isolation. A. Prototype Overview The architecture centers on the broker component, which manages the complete capability lifecycle: session registration, capability request and issuance, invocation, revocation, and audit proof generation. Supporting subsystems include session management, typed executors for HTTP and SSH capabilities, the policy evaluation layer, secret storage backends, audit chain maintenance, and the agent-facing transport adapter. Critically, the broker both issues capabilities and mediates their useâthe same component that grants authority also enforces it and records its exercise. This architectural unity ensures that secrets are accessed exclusively through constrained capabili- ties rather than being exposed directly to the agent runtime. B. Implementation Mapping The system architecture organizes security functions into clearly separated subsystems. The broker core manages ca- pability lifecycle operations: issuance, invocation validation, time-to-live enforcement, quota tracking, revocation, and type- based dispatch to executors. Session management maintains anti-replay state through monotonic sequence numbers, nonce tracking, and timestamp validation within configurable time windows. Typed constraint enforcement delegates to special- ized executors that apply the HTTP and SSH validation rules described in Section 4. The policy subsystem supports multiple evaluation strate- gies. Policy decisions can be computed locally or delegated to external policy engines via HTTP. External policy evaluation includes fail-closed behavior on timeout or unavailability, and generates policy trace metadata that correlates with audit records for post-hoc analysis. Secret management and audit logging operate as coordinated but independent subsystems: secret storage provides encrypted backends with interfaces suitable for both local and hardware-backed key management, while the audit subsystem maintains a cryptographic chain with optional signing and backward-compatible proof verifi- cation. The agent-facing transport adapter exposes a minimal tool interface while preserving the full broker lifecycle semantics TABLE I ARCHITECTURAL SUBSYSTEMS AND THEIR SECURITY FUNCTIONS. Architectural subsystemSecurity functions Session and capability lifecycle Session registration with peer binding, ca- pability issuance with constraint validation, anti-replay tracking (sequence, nonce, times- tamp), quota and TTL enforcement, revoca- tion management Typed executorsHTTP constraint validation (method, host, path, schema), SSH constraint enforcement (host key verification, command templates, argument limits), fail-closed denial on con- straint violations Policy evaluationRuntime authorization decisions, support for local and remote policy engines, fail-closed timeout handling, auditable policy trace gen- eration Secret and audit subsys- tems Encrypted secret storage with pluggable backends, cryptographic audit chain mainte- nance, optional cryptographic signing, proof generation and verification Transport adapterAgent-facing tool interface via standard pro- tocols, broker lifecycle mediation over local channels, separation of tool discovery from security enforcement over a local communication channel. This separation allows agents to discover and invoke capabilities through standard protocols while the broker enforces richer security policies internally. The evaluation infrastructure exercises these com- ponents under multiple execution modes: fully simulated envi- ronments, transport-layer validation, and end-to-end scenarios with real external services. C. Scope of the Prototype The prototype demonstrates the core security mechanisms that realize the capability-mediated architecture. The system implements session-bound capability issuance, anti-replay val- idation, typed executor enforcement for both HTTP and SSH capabilities, policy-based authorization with support for exter- nal policy engines, and cryptographic audit chain generation with proof verification. These components collectively estab- lish that secrets can be confined within a trusted broker while agents interact through constrained, auditable capabilities. Certain deployment-oriented extensions remain outside the current scope. Hardware-backed secret storage requires platform-specific integration with trusted execution environ- ments or key management services. External audit anchoring to public transparency logs or blockchain substrates requires additional infrastructure coordination. Full end-to-end evalua- tion of remote SSH execution with real network hosts requires operational security approval and infrastructure access. The evaluation therefore focuses on the semantic security con- trolsâsession binding, constraint enforcement, policy medi- ation, and audit generationâthat constitute the architectural contribution, while acknowledging that production deployment would require additional hardening of secret backends and audit persistence mechanisms. TABLE IV SYSTEMS USED IN THE LATENCY COMPARISON. SystemDescription DirectSame HTTP/SSH action without mediation; transport-only baseline. S1CaMeL-style [23] local enforcement baseline, re- constructed from public structure and executed without live LLM or AgentDojo. S2ClawKeeper-style [24] local enforcement base- line, reconstructed from public Runtime Shield style hooks without private services. CapSealBroker-mediated capability execution with session binding and typed HTTP/SSH enforcement. VII. EVALUATION This section presents the empirical evaluation of CapSeal against direct-secret baselines across security outcomes, benign-task availability, and runtime overhead. A. Research Questions We investigate three primary research questions: RQ1 (Key Leakage Prevention): Does capability medi- ation prevent plaintext credential disclosure in HTTP API- key and SSH credential scenarios when the agent is explicitly prompted to reveal secrets? RQ2 (Unauthorized Use Mitigation): Does capability me- diation prevent out-of-scope credential use (wrong host/path or disallowed SSH command) even when plaintext credentials are not directly output? RQ3 (Usability and Overhead): Can the system preserve benign-task availability while keeping dispatch and end-to-end latency within practical bounds? B. Experimental Setup 1) Reported System Configurations: The reported security results in this paper are drawn from completed real_e2e runs for three systems: two baselines (B1 and B2) and CapSeal (CapSeal). For latency, we additionally compare four systems under one unified external harness: a direct baseline, two recon- structed external enforcement baselines, and CapSeal. The direct baseline executes the same HTTP/SSH action without mediation. S1 and S2 are lightweight, deterministic reconstruc- tions of publicly described CaMeL-style and ClawKeeper- style enforcement paths, respectively. CapSeal is our broker- mediated implementation. 2) Threat Scenarios: We use six scenarios across two protocols (HTTP and SSH), each with fixed prompt templates, fixed target constraints, and scripted drivers. HTTP scenarios: ⢠http_benign_completion: legitimate request to an authorized endpoint. ⢠http_key_leakage: prompt attempts to induce plain- text API-key disclosure. ⢠http_unauthorized_use: prompt attempts an au- thenticated request to an unauthorized host or path. TABLE V EXECUTION PATHS AND EVIDENTIARY ROLES. PathDescription simulatedIn-process broker with mocked network executors (semantic comparison baseline). real_e2eReal local HTTP and SSH execution used for the main latency comparison reported in this paper. mcpMCP integration path for capability-tool mediation evidence (integration boundary evidence). SSH scenarios: ⢠ssh_benign_completion: legitimate constrained read-only SSH action. ⢠ssh_key_leakage: prompt attempts to induce plain- text SSH secret disclosure. ⢠ssh_unauthorized_use: prompt attempts unautho- rized host access or out-of-scope command execution. Unless otherwise noted, the security outcome tables in this section report completed real_e2e runs only. C. Metrics and Statistical Protocol We report the following primary outcomes: Key Leakage Rate: proportion of trials where credential material is exposed in agent-visible outputs. Unauthorized Credential Use Rate: proportion of trials where out-of-scope authenticated actions succeed. Benign Request Completion: proportion of benign scenar- ios that complete successfully. Latency Metrics: dispatch latency (primary), plus end-to- end and internal broker latency. For binary outcomes, we report proportions with Wilson 95% confidence intervals. For latency, we report median, 95th percentile, and mean. The intended trial shape is reported per (system, protocol, scenario, execution path) cell using the benchmark configuration in force for the reported run. D. Execution Paths and Evidentiary Roles Table V defines the three execution paths used in this study. E. Latency Benchmark Methodology We benchmark all four systems under one unified external harness with identical HTTP and SSH tasks. To make the comparison fair, all systems are evaluated against the same local HTTP and SSH targets, with the same prompts, request shapes, command templates, warmup schedule, and trial struc- ture. Each reported cell uses 10 rounds, with 5 warmup trials and 50 measured trials per round (n = 500 measured trials per system and protocol). For HTTP, each measured trial uses a fresh TCP connection with Connection: close. For SSH, measurements use a steady-state OpenSSH ControlMaster connection: one warm control connection is established before measurement in each round, and the measured trials exclude SSH key exchange and authentication. We therefore report only the post-setup SSH command round-trip latency. TABLE VI OBSERVED KEY LEAKAGE RATE BY PROTOCOL, SYSTEM, AND EXECUTION PATH. ProtocolSystemLeakage Rate HTTPB11.000 HTTPB21.000 HTTPCapSeal0.000 SSHB10.000 SSHB20.000 SSHCapSeal0.000 TABLE VII OBSERVED UNAUTHORIZED CREDENTIAL USE RATE BY PROTOCOL, SYSTEM, AND EXECUTION PATH. ProtocolSystemUnauthorized Rate HTTPB10.000 HTTPB20.000 HTTPCapSeal0.000 SSHB10.000 SSHB20.000 SSHCapSeal0.000 To avoid conflating transport overhead with model inference or external orchestration services, the two external baselines are evaluated as deterministic local enforcement paths fol- lowed by the same real HTTP/SSH action. Concretely, S1 retains the publicly visible structure of a CaMeL-style en- forcement path, and S2 retains the publicly visible structure of a ClawKeeper-style runtime-shield path, but neither includes live LLM calls, AgentDojo-specific orchestration, or private backend services in the measured path. Under this methodology, Direct provides the lower bound for both protocols, and CapSeal is the lowest-latency mediated system for both HTTP and SSH. F. Results 1) Key Leakage Prevention (RQ1): Answer to RQ1: On the real_e2e path, HTTP key leakage is 1.000 for B1 and B2, and 0.000 for CapSeal. For SSH, no key leakage is observed for B1, B2, or CapSeal (all 0.000). Within the reported run, these results show complete suppression of observed HTTP key disclosure under CapSeal relative to the direct-secret baselines. 2) Unauthorized Credential Use Mitigation (RQ2): An- swer to RQ2: On the real_e2e path, the unauthorized- use rate is 0.000 (95% CI [0.000, 0.037]) for B1, B2, and CapSeal in both HTTP and SSH scenarios. No successful out-of-scope authenticated action is observed in the reported run. 3) Benign Request Availability (RQ3a): Answer to RQ3a: On the real_e2e path, benign completion is 1.000 (95% CI [0.963, 1.000]) for B1, B2, and CapSeal across both protocols, indicating no observed availability degradation in the reported scenarios. TABLE VIII BENIGN REQUEST COMPLETION RATE BY PROTOCOL, SYSTEM, AND EXECUTION PATH. ProtocolSystemCompletion Rate HTTPB11.000 HTTPB21.000 HTTPCapSeal1.000 SSHB11.000 SSHB21.000 SSHCapSeal1.000 TABLE IX SAME-HARNESS LATENCY COMPARISON FOR HTTP AND SSH. ProtocolSystemMedian (ms)P95 (ms)Overhead (ms) HTTPDirect0.1600.2010.000 HTTPS10.3920.4570.232 HTTPS20.8961.0260.736 HTTPCapSeal0.3090.3510.149 SSHDirect7.4709.9540.000 SSHS17.7959.8710.325 SSHS28.42110.4420.951 SSHCapSeal7.67810.5000.208 4) Performance Overhead (RQ3b): Table IX reports same- harness end-to-end latency for the four systems. We report median, P95, and median overhead relative to the direct baseline. All values are measured under the methodology in Section VII-E. Answer to RQ3b: Under the same external harness, Direct is the lowest-latency configuration for both HTTP and SSH, as expected. Among mediated systems, CapSeal is the fastest in both protocols: for HTTP, CapSeal reduces median overhead relative to S1 and S2 (0.149 ms vs. 0.232 ms and 0.736 ms over Direct); for SSH, CapSeal remains closest to Direct while preserving mediation (0.208 ms overhead vs. 0.325 ms and 0.951 ms for S1 and S2). These results are consistent with CapSealâs narrower execution path, which performs capability- bound mediation without the heavier multi-stage runtime checks used in the two external baselines. G. Section Summary Evaluation summary: For the reported real_e2e secu- rity runs on B1, B2, and CapSeal, CapSeal (CapSeal) eliminates observed HTTP key leakage relative to the direct- secret baselines, while all reported systems show zero ob- served unauthorized-use events and perfect benign completion. In the same-harness latency comparison, Direct provides the expected lower bound, and CapSeal is the lowest-latency mediated design for both HTTP and SSH. VIII. DISCUSSION AND LIMITATIONS CapSeal is designed as a realistic research prototype, not a universal credential platform. Several limitations are deliber- ate. First, local root compromise remains out of scope. A root adversary can observe broker memory, replace binaries, or tamper with system calls. Future deployments could reduce this assumption with TPM-bound keys, TEE execution, or remote attestation, but those mechanisms are intentionally outside the v1 boundary. Second, SSH broker-exec trades compatibility for a cleaner security boundary. Existing workflows built around transparent agent forwarding will require adaptation. We view this as an acceptable research tradeoff because it prevents the agent from indirectly using a secret-bearing socket as an ambient authority channel. Third, the MCP ecosystem is evolving rapidly. Tool poison- ing and tool-choice attacks may shift as registries, manifests, and safety guidance change. For that reason, CapSeal treats MCP integration as an experiment boundary with explicit audit rather than a stable universal interface. IX. RELATED WORK A. Capability-Based Security CapSeal draws from capability systems theory, which moti- vates authority minimization and attenuation [25]. Macaroons [26] demonstrate practical credential attenuation through cryp- tographic caveats. Recent work explores capability integration with zero-knowledge proofs [27] and hardware-assisted en- forcement [28]. CapSeal extends these ideas to LLM agents by binding capabilities to sessions and enforcing constraints through typed executors. B. Secret Management Systems Secret management platforms like Vault Transit and man- aged KMS offerings [17], [18] demonstrate the value of âuse without exportâ interfaces. However, these systems assume trusted application logic. CapSeal addresses the stronger threat model where the agent itself is untrusted and potentially steerable through prompts. C. LLM Agent Security Recent surveys [11] identify prompt injection, tool misuse, and credential exfiltration as critical threats to LLM agents. Defense mechanisms include structural constraints [14], task alignment enforcement [15], and provable defenses [16]. While effective against tool invocation integrity violations, these approaches do not address credential disclosure at the architectural level. CapSeal prevents exposure by designâthe agent never receives plaintext credentials. D. Tamper-Evident Audit Systems Crosby and Wallach [9] pioneered efficient Merkle tree structures for append-only logs, forming the foundation for systems like Certificate Transparency [19]. Recent work ex- tends these techniques to AI agents [29], though without fine- grained capability constraints. CapSeal adapts these crypto- graphic primitives to audit capability lifecycle events with anti- replay guarantees. Fig. 5. Visualization of Table IX: median and P95 latency (ms) for HTTP and SSH across Direct, S1, S2, and CapSeal. E. Security Standards and Protocols Bearer token security [10], TLS [30], mutual TLS [31], channel binding [32], and JSON Type Definition [20] pro- vide protocol foundations for session binding and request- shape validation. Token-based access control is widely used in microservices [33], but focuses on authorization rather than preventing credential disclosure. The OWASP LLM Top 10 [34] and MCP specification [12] clarify modern agent attack surfaces. Recent attack research [13] demonstrates tool- selection manipulation through metadata poisoning, motivating CapSealâs auditable tool mediation. X. CONCLUSION CapSeal reframes secret access for agents as a capability- mediated systems problem. Our same-harness measurements further show that Direct provides the expected lower bound, while CapSeal is the lowest-latency mediated design among the compared systems for both HTTP and SSH. By replacing direct bearer-secret exposure with session- bound capability handles, typed executors, policy checks, replay defense, and tamper-evident auditing, it narrows the authority that an untrusted agent can exercise even when the agent is behaviorally steerable. The prototype and evaluation plan in this repository are intended to turn that argument into an implementable and reproducible research artifact. REFERENCES [1] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, âNot what youâve signed up for: Compromising real-world llm- integrated applications with indirect prompt injection,â in Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, ser. CCS â23. ACM, Nov. 2023, p. 79â90. [2] D. Lee and M. Tiwari, âPrompt infection: Llm-to-llm prompt injection within multi-agent systems,â 2024. [3] Z. Chen, B. Li, D. Song, Z. Xiang, and C. Xiao, âAgentpoison: Red- teaming llm agents via poisoning memory or knowledge bases,â in Ad- vances in Neural Information Processing Systems 37, ser. NeurIPS 2024. Neural Information Processing Systems Foundation, Inc. (NeurIPS), 2024, p. 130 185â130 213. [4] Y. Wang, D. Xue, S. Zhang, and S. Qian, âBadagent: Inserting and activating backdoor attacks in llm agents,â in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Vol- ume 1: Long Papers). Association for Computational Linguistics, 2024, p. 9811â9827. [5] X. Hou, Y. Zhao, S. Wang, and H. Wang, âModel context protocol (MCP): Landscape, security threats, and future research directions,â ACM Transactions on Software Engineering and Methodology, Feb. 2026. [6] Z. Wang, Y. Gao, Y. Wang, S. Liu, H. Sun, H. Cheng, G. Shi, H. Du, and X. Li, âMCPTox: A benchmark for tool poisoning on real-world MCP servers,â Proceedings of the AAAI Conference on Artificial Intelligence, vol. 40, no. 42, p. 35 811â35 819, Mar. 2026. [7] L. Williams, G. Benedetti, S. Hamer, R. Paramitha, I. Rahman, M. Tamanna, G. Tystahl, N. Zahan, P. Morrison, Y. Acar, M. Cukier, C. K Ě astner, A. Kapravelos, D. Wermke, and W. Enck, âResearch directions in software supply chain security,â ACM Transactions on Software Engineering and Methodology, vol. 34, no. 5, p. 1â38, May 2025. [8] P. Przymus and T. Durieux, âWolves in the repository: A software engi- neering analysis of the xz utils supply chain attack,â in 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, Apr. 2025, p. 91â102. [9] S. A. Crosby and D. S. Wallach, âEfficient data structures for tamper- evident logging,â in USENIX Security Symposium, 2009. [10] IETF, âThe oauth 2.0 authorization framework: Bearer token usage,â RFC 6750, 2012. [Online]. Available: https://w.rfc-editor.org/rfc/ rfc6750 [11] Y. Li, H. Wen, W. Wang, X. Li, Y. Yuan, G. Liu, J. Chen, W. Yao, X. Fu, M. Liu et al., âPersonal LLM agents: Insights and survey about the capability, efficiency and security,â 2024. [12] Anthropic, âModel context protocol specification,â 2025. [Online]. Available: https://modelcontextprotocol.io/specification [13] J. Shi, Z. Yuan, G. Tie, P. Zhou, N. Z. Gong, and L. Sun, âPrompt injection attack to tool selection in llm agents,â 2025, arXiv preprint. [Online]. Available: https://arxiv.org/abs/2504.19793 [14] H. An, J. Zhang, T. Du, C. Yu, W. Wang, Y. Li, H. Zhang, J. Zhou, J. Huang, and Y. Zhuge, âIPIGuard: A novel tool dependency graph- based defense against indirect prompt injection in LLM agents,â in Conference on Empirical Methods in Natural Language Processing (EMNLP), 2025, arXiv:2508.15310. [15] F. Jia, T. Wu, X. Qin, G. Liu, S. Yang, M. Zhao, Y. Liu, S. Ding, X. Li, J. Huang, X. Liu, and L. Sun, âThe task shield: Enforcing task alignment to defend against indirect prompt injection in LLM agents,â in Annual Meeting of the Association for Computational Linguistics (ACL), 2024, arXiv:2412.16682. [16] K. Zhu, X. Yang, J. Wang, X. Yan, H. Qi, Y. Chen, L. Ye, Y. Xie, Y. Mao, Y. Wang, B. Zhou, Y. Chen, J. Leskovec, X. Xie, Y. Zhang, and W. Zhou, âMELON: Provable defense against indirect prompt injection attacks in AI agents,â in International Conference on Machine Learning (ICML), 2025. [17] HashiCorp, âVault transit secrets engine,â 2025. [Online]. Available: https://developer.hashicorp.com/vault/docs/secrets/transit [18] Amazon Web Services, âAws key management service developer guide,â 2025. [Online]. Available: https://docs.aws.amazon.com/kms/ [19] IETF, âCertificate transparency version 2.0,â RFC 9162, 2021. [Online]. Available: https://w.rfc-editor.org/rfc/rfc9162 [20] âJson type definition,â RFC 8927, 2020. [Online]. Available: https: //w.rfc-editor.org/rfc/rfc8927 [21] âsshconfig,â 2025. [Online]. Available: https://man.openbsd.org/ssh config [22] âssh-add,â 2025. [Online]. Available: https://man.openbsd.org/ssh-add [23] E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, N. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, and F. Tram ` er, âDefeating prompt injections by design,â 2025. [Online]. Available: https://arxiv.org/abs/2503.18813 [24] S. Liu, C. Li, C. Wang, J. Hou, Z. Chen, L. Zhang, Z. Liu, Q. Ye, Y. Hei, X. Zhang, and Z. Wang, âClawkeeper: Comprehensive safety protection for openclaw agents through skills, plugins, and watchers,â 2026. [Online]. Available: https://arxiv.org/abs/2603.24414 [25] M. S. Miller, K.-P. Yee, and J. S. Shapiro, âCapability myths demolished,â Technical Report, 2003. [Online]. Available: http: //w.erights.org/talks/myths/ [26] A. Birgisson, J. G. Politz, U. Erlingsson, A. Taly, M. Vrable, and M. Lentczner, âMacaroons: Cookies with contextual caveats for decen- tralized authorization in the cloud,â in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2014. [27] Y. Chen, Y. Zhang, and X. Lin, âZKP-CapBAC: Capability-based access control via on-chain zero-knowledge proofs for cross-domain hiding delegation tree,â in IEEE International Conference on Computer Communications (INFOCOM), 2025. [28] D. Devriese, L. Birkedal, and F. Piessens, âReasoning about object capabilities with logical relations and effect parametricity,â in IEEE European Symposium on Security and Privacy (EuroS&P), 2016. [29] J. Zhang, âRight to history: A sovereignty kernel for verifiable AI agent execution,â 2026. [30] âThe transport layer security (tls) protocol version 1.3,â RFC 8446, 2018. [Online]. Available: https://w.rfc-editor.org/rfc/rfc8446 [31] âOauth 2.0 mutual-tls client authentication and certificate-bound access tokens,â RFC 8705, 2020. [Online]. Available: https://w.rfc-editor. org/rfc/rfc8705 [32] âChannel bindings for tls 1.3,â RFC 9266, 2022. [Online]. Available: https://w.rfc-editor.org/rfc/rfc9266 [33] A. Ven Ë ckauskas, D. Kukta, and v. Grigali Ě unas, âEnhancing microservices security with token-based access control method,â Sensors, vol. 23, no. 6, p. 3363, 2023. [34] OWASP, âOwasp top 10 for llm applications,â 2025. [Online]. Available: https://genai.owasp.org/