S — Spoofing
Threat: A process impersonates a legitimate client to obtain injected credentials. Mitigation: Loopback-only binding. Only processes on the local machine can reach the proxy. There is no authentication mechanism because the network boundary (loopback) is the authentication boundary. Residual risk: Any process running as the same user can connect. Same-user process isolation is the operating system’s responsibility, not the proxy’s.T — Tampering
Threat: An attacker modifies requests in transit to redirect credentials to an unintended destination. Mitigation: Auth header stripping replaces any inbound Authorization header unconditionally. The SSRF denylist blocks private and internal IP destinations. Upstream TLS prevents man-in-the-middle on the proxy-to-API leg. Residual risk: If DNS resolution returns a public IP controlled by an attacker (and the route config matches that host), the credential will be sent. DNS pinning closes the TOCTOU window but cannot prevent a legitimately-resolved malicious IP.R — Repudiation
Threat: An agent denies having made a specific API call through the proxy. Mitigation: Structured logs record route matches, upstream destinations, and request metadata. Credentials and Authorization header values are never logged. Log correlation enables attribution to specific proxy sessions. Residual risk: Local logs can be modified by any process with file access. There is no tamper-evident audit chain in the local deployment model. Managed deployments will address this with centralized, immutable logging.I — Information Disclosure
Threat: Credentials leak through logs, memory dumps, debug output, or the agent’s context window. Mitigation: TheSecret type has no Debug or Display impl; attempts to log or format a secret fail at compile time, not at runtime via redaction. Explicit access is required to retrieve the underlying value through token-gated callbacks, making every use visible in code review. #![forbid(unsafe_code)] prevents circumventing the type system. Credentials are zeroized on drop. Credentials never enter the agent’s environment — the agent configures a proxy URL, not a credential.
Residual risk: A memory dump of the running proxy process could capture secrets that have not yet been zeroized. The window is bounded by request duration (typically milliseconds). Core dumps should be disabled or restricted in sensitive environments.
When using the 1Password backend, credential source tooling introduces an additional side channel. Cordon invokes the op CLI, and depending on how the session is authenticated (desktop app biometric, shell-based sign-in, or service account token), other same-user processes may be able to invoke op independently and extract secrets from 1Password, bypassing the proxy. This is an inherent property of using an external CLI as a credential backend — Cordon cannot restrict which processes invoke op. See the 1Password security considerations for details on which authentication methods are affected and available mitigations.
D — Denial of Service
Threat: A malicious or runaway agent floods the proxy, exhausting resources or upstream API rate limits. Mitigation: The proxy is single-tenant (one developer’s machine). The blast radius of a denial-of-service is limited to that developer’s own API quotas. There is no shared infrastructure to disrupt. Residual risk: An agent could exhaust the developer’s API rate limits. This is an operational concern, not a security boundary violation. Rate limiting at the proxy layer is a potential future enhancement.E — Elevation of Privilege
Threat: An agent or process accesses credentials for routes it should not have access to. Mitigation: All configured routes are equally accessible to any local process. Route configuration is the developer’s explicit trust decision — there is no per-process or per-agent access control in the local deployment model. Residual risk: Any process that can reach the proxy can trigger credential injection for any configured route. Per-caller authorization is planned for managed deployments.SSRF attacker model
The primary SSRF threat comes from AI agents or LLM-generated code that controls the destination of HTTP requests routed through the proxy. Attacker capabilities:- Controls the destination host, port, path, headers, and body
- Can make arbitrary HTTP requests through the proxy
| Target | Risk |
|---|---|
Cloud metadata (169.254.169.254) | IAM credential theft |
| Localhost services | Data exfiltration, RCE |
| Private networks (RFC 1918) | Lateral movement |
- All resolved IPs checked against the denylist before connection
- IPv6 transition addresses have embedded IPv4 extracted and re-checked
- DNS pinning prevents TOCTOU attacks via DNS rebinding
- Configured routes are exempt (explicit trust decision by the developer)
Out of scope
The following threats are outside the proxy’s trust boundary or are managed by other systems.| Threat | Rationale |
|---|---|
| Local machine compromise | Root or admin access can read keychain entries, process memory, and loopback traffic. Same-user processes can connect to the proxy and (on Linux) read keyring entries. The trust boundary is the local operating system. |
| Response data sensitivity | API responses flow back to the agent in cleartext. Cordon protects credentials, not the data those credentials access. A prompt-injected agent could exfiltrate sensitive response data. This is inherent to any credential proxy model. |
| Supply chain attacks | Managed by dependency auditing and SAST in CI, not by Cordon’s runtime security model. |
| Credential source compromise | If 1Password or the OS keyring is compromised, the attacker has the secrets regardless of Cordon. When using the op CLI backend, the pre-authenticated session may be accessible to other same-user processes depending on the authentication method — this is a property of the CLI-based integration, not a Cordon vulnerability. The proxy trusts the credential source by design; restricting local CLI access is outside its trust boundary. See 1Password security considerations. |