# Threat Model

Security claims are only meaningful when scoped. This page is a transparent analysis of what Keychains protects against, what it doesn't, and where the boundaries lie.

## Protection Matrix

Keychains keeps credentials out of the agent's context, making them impossible to extract via prompt injection. However, prompt injection can still manipulate _which_ API calls the agent makes within its approved scopes. Keychains limits the blast radius — it doesn't eliminate the threat.

| Attack Vector | Protected? | Explanation |
| --- | --- | --- |
| Credential exfiltration via prompt injection | Yes | Credentials never enter the agent's context window. There is nothing to exfiltrate. |
| Scope escalation beyond approved set | Yes | The proxy enforces scope boundaries server-side. An agent cannot access APIs or scopes it hasn't been approved for. |
| Credential redirection to attacker-controlled endpoint | Yes | The proxy enforces strict destination binding. Each credential can only be forwarded to its designated provider's API endpoints. |
| SSH private key theft | Partially | Stateful fingerprinting and rolling hash chains detect concurrent use from different machines. If the real machine is idle, detection depends on the next legitimate call. |
| Permission token theft | Partially | Short TTL (5-15 min) limits the window. Revocation is instant via server-side state check on every call. But a stolen token works until expiry or revocation. |
| Social engineering user to approve scopes | Partially | Users see exactly what scopes are requested, but may not fully understand the implications. Approval fatigue is a real risk. |
| Unauthorized API calls within approved scopes | No | The agent can be tricked into making calls it shouldn't within already-approved scopes. The proxy authenticates — it doesn't inspect intent. |
| Response data exfiltration | No | API responses flow back to the agent in cleartext. Keychains protects credentials, not the data returned by APIs. |

## Known Limitations

### Within-scope manipulation

If an agent is approved for `github::repo`, a prompt injection could trick it into deleting repositories instead of reading them. Keychains verifies the scope, not the action.

### Response data exposure

API responses may contain PII and sensitive data. Keychains protects credentials but the data returned by APIs flows back to the agent. This is a fundamental property of the proxy architecture.

### Runtime environment trust

Credentials are decrypted in memory during the proxy request. The proxy runs on Vercel's serverless infrastructure — a trusted but shared cloud environment.

## What We Recommend

- 1 Use the narrowest scopes possible. Don't approve `github::*` when `github::repo:read` suffices.
- 2 Review the audit log regularly. Unusual patterns (bulk deletions, unexpected providers) are your early warning system.
- 3 Revoke permissions you no longer need. Keychains makes this instant — use it.
- 4 For sub-agents, use scoped delegate tokens with the minimum required permissions.

[Key & Token Security](/content/docs/security/index.html) [Security Overview](/content/security/index.html)