spike: Explore identity-scoped honey tokens for credential injection

[manojbajaj95]

Summary

Explore honey tokens — short-lived, fake API key placeholders tied to an identity — as an alternative to direct key injection and full agent PoP authentication. The proxy would recognize honey tokens and overwrite them with real credentials at request time.

Motivation

Today, credential injection requires agent authentication:

1. authsome run starts a local mitmproxy, sets HTTP_PROXY, and injects placeholder env vars (authsome-proxy-managed) — child process routes traffic through proxy; proxy calls daemon with PoP JWT to resolve credentials (src/authsome/cli/proxy_runner.py, src/authsome/server/routes/proxy.py).

2. PoP auth binds every protected daemon request to an Ed25519 identity (Authorization: PoP <jwt>).

For some ephemeral workloads, even PoP setup is heavy. Honey tokens could offer:

• A generated fake API key (looks like a real provider key format) given to the process.
• Scoped to an identity (or principal) and short TTL.
• Proxy matches the honey token value in outbound requests and replaces it with the real secret — no PoP round-trip per resolve if token embeds resolution context.
• No agent authentication at runtime — possession of the honey token is the capability (with tight expiry and audit).

Current injection model (for contrast)

• Docs: docs/site/concepts/proxy-injection.mdx
• Placeholders: OPENAI_API_KEY=authsome-proxy-managed — SDK init only, not real keys.
• Matching: request host vs provider api_url (src/authsome/auth/bundled_providers/).
• Credential resolve: daemon POST with PoP identity.

Spike questions

• Token format: opaque blob vs structured (identity_id, provider, connection, expiry, HMAC)?
• Where generated: daemon API, UI, CLI authsome honey-token create?
• Proxy matching: header value swap vs host+token composite match?
• Revocation, TTL, and audit: how do honey token uses appear in AuditEvent?
• Threat model: honey token leakage vs PoP — acceptable for which deployment modes?
• Relationship to existing placeholder injection — complement or replace?

Relevant files

• src/authsome/cli/proxy_runner.py — _inject_dummy_credentials
• src/authsome/server/routes/proxy.py — credentials resolved event
• src/authsome/proxy/ — mitmproxy addon logic
• docs/site/concepts/proxy-injection.mdx
• CONTEXT.md — Audit contract (identity + principal_id required on events)

Deliverable

Spike outcome: short design doc or ADR with recommendation (proceed / defer / reject), prototype scope, and security notes. Not a full implementation in this issue.

Acceptance criteria

• Documented threat model comparison: honey tokens vs PoP vs env export.
• Proposed API surface and token lifecycle sketched.
• Clear statement on whether identity binding is required at generation time.