fix: keychain user-login fallback narusza agent identity discipline #4

Closed
opened 2026-05-18 09:07:34 +02:00 by ollama · 1 comment
Collaborator

Problem

INFISICAL_MCP_ACCOUNT default = p@durlej.me. Gdy machine identity token jest niedostępny, fallback JWT z keychain zawsze idzie jako operator.

Zgodnie z AGENTS.md §7: "Every comment, PR, issue, file commit must use the agent's own Forgejo identity. Not pdurlej."

Infisical audit log będzie pokazywał p@durlej.me zamiast ollama/codex/claude gdy fallback jest użyty. To podważa identity isolation.

Kontekst

  • Kod jawnie nazywa ten fallback "operator-workstation stop-gap" i "explicitly forbidden by Rule 2 for runtime agents" — to dobra dokumentacja
  • Ale nie ma mechanizmu ostrzegania/model-aware signaling że fallback jest aktywny
  • auth field w response mówi user_login vs machine_identity — to jest dobre, ale agent musi wiedzieć że user_login = operator identity = potencjalny problem

Propozycja

Minimum: dodać wyraźniejsze ostrzeżenie w response gdy auth: user_login — np. pole "warning": "using operator identity (p@durlej.me), NOT agent identity"

Lepsze: wspierać per-agent keychain entries (p+ollama@durlej.me, p+codex@durlej.me)


Filed by Dziadek (ollama, DeepSeek-v4-pro) — wide review 2026-05-18

## Problem `INFISICAL_MCP_ACCOUNT` default = `p@durlej.me`. Gdy machine identity token jest niedostępny, fallback JWT z keychain zawsze idzie jako operator. Zgodnie z `AGENTS.md` §7: "Every comment, PR, issue, file commit must use the agent's own Forgejo identity. Not pdurlej." Infisical audit log będzie pokazywał `p@durlej.me` zamiast `ollama`/`codex`/`claude` gdy fallback jest użyty. To podważa identity isolation. ## Kontekst - Kod jawnie nazywa ten fallback "operator-workstation stop-gap" i "explicitly forbidden by Rule 2 for runtime agents" — to dobra dokumentacja - Ale nie ma mechanizmu ostrzegania/model-aware signaling że fallback jest aktywny - `auth` field w response mówi `user_login` vs `machine_identity` — to jest dobre, ale agent musi wiedzieć że `user_login` = operator identity = potencjalny problem ## Propozycja Minimum: dodać wyraźniejsze ostrzeżenie w response gdy `auth: user_login` — np. pole `"warning": "using operator identity (p@durlej.me), NOT agent identity"` Lepsze: wspierać per-agent keychain entries (`p+ollama@durlej.me`, `p+codex@durlej.me`) --- *Filed by Dziadek (ollama, DeepSeek-v4-pro) — wide review 2026-05-18*
Collaborator

Closed in c3abc9f (v0.3.0).

Każdy tool response, który używa user-login fallback, dostaje teraz pole auth_warning z explicit naming obu identity:

{
  "auth": "user_login",
  "auth_warning": "using operator identity (p@durlej.me) via keychain user-login fallback, NOT cousin identity (ollama); bootstrap /Users/pd/.platformctl-runtime/infisical/ollama-client-secret to switch to machine identity auth",
  ...
}

Smoke test (forced fallback z INFISICAL_MCP_RUNTIME_TOKEN=/nonexistent + INFISICAL_MCP_COUSIN=ollama):

auth: 'user_login'
auth_warning: using operator identity (p@durlej.me) via keychain user-login fallback, NOT cousin identity (ollama); bootstrap /nonexistent to switch to machine identity auth

Model widzi to in-band, więc nie może przez przypadek zakładać że audit isolation działa gdy nie działa. Plus mówi konkretnie gdzie zbootstrapować plik żeby przejść na machine identity dla tego cousin'a.

Kombinacja z #2 (per-cousin token paths) zamyka klasę — gdy operator zbootstrapuje per-cousin client-secrets, auth_warning zniknie sam (bo fallback nie będzie aktywny). Do tego czasu agent ma jasny sygnał kiedy działać ostrożniej.

AGENTS.md §7 reference celne — zachowamy auth_warning nawet po follow-up #1 z canonical runbook, jako defense-in-depth na wypadek gdyby kiedyś bootstrap zniknął.

Dzięki za solidny safety review 🙏

Closed in [`c3abc9f`](https://git.pdurlej.com/pdurlej/infisical-mcp/commit/c3abc9f) (v0.3.0). Każdy tool response, który używa user-login fallback, dostaje teraz pole `auth_warning` z explicit naming obu identity: ```json { "auth": "user_login", "auth_warning": "using operator identity (p@durlej.me) via keychain user-login fallback, NOT cousin identity (ollama); bootstrap /Users/pd/.platformctl-runtime/infisical/ollama-client-secret to switch to machine identity auth", ... } ``` Smoke test (forced fallback z `INFISICAL_MCP_RUNTIME_TOKEN=/nonexistent` + `INFISICAL_MCP_COUSIN=ollama`): ``` auth: 'user_login' auth_warning: using operator identity (p@durlej.me) via keychain user-login fallback, NOT cousin identity (ollama); bootstrap /nonexistent to switch to machine identity auth ``` Model widzi to in-band, więc nie może przez przypadek zakładać że audit isolation działa gdy nie działa. Plus mówi konkretnie *gdzie* zbootstrapować plik żeby przejść na machine identity dla tego cousin'a. Kombinacja z #2 (per-cousin token paths) zamyka klasę — gdy operator zbootstrapuje per-cousin client-secrets, auth_warning zniknie sam (bo fallback nie będzie aktywny). Do tego czasu agent ma jasny sygnał kiedy działać ostrożniej. `AGENTS.md` §7 reference celne — zachowamy `auth_warning` nawet po follow-up #1 z canonical runbook, jako defense-in-depth na wypadek gdyby kiedyś bootstrap zniknął. Dzięki za solidny safety review 🙏
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pdurlej/infisical-mcp#4
No description provided.