docs(personas): record why hermes, homeassistant and litellm block personas

The persona contract expects every role to exercise the administrator and
biber personas, and requires a persona-block-rationale where one cannot reach
the application at all. 68 roles already carry it; these three did not.

Each rationale names the mechanism, and each was checked against the
declaration rather than taken at face value:

- hermes admits only the administrator and mcp RBAC groups to its oauth2
  proxy, so biber is refused at the proxy. allowed_groups lists exactly those
  two.
- homeassistant runs its own auth provider with sso.enabled false, and its
  hub account comes from secrets.credentials.administrator_password rather
  than the platform user password.
- the litellm admin UI has no platform-user concept, authenticating with the
  UI_USERNAME/UI_PASSWORD pair the service provisions, with sso.enabled
  false.

Both sso pins verified as false in meta/services.yml.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
kevinveenbirkenbachandClaude Opus 5 committed 2026-08-28 12:59:16 +02:00
1 parent 896b72428c
commit aef525f913
3 files changed
+5

No files matched your search

@@ -29,6 +29,7 @@ MCP_SERVICE_ENABLED={{ lookup('config', application_id, 'mcp.enabled') | string
OIDC_ISSUER_URL={{ OIDC.CLIENT.ISSUER_URL | dotenv_quote }}
# nocheck: persona-block-rationale: meta/services.yml admits only the web-app-hermes administrator and mcp RBAC groups to the oauth2 proxy (sso.oauth2.allowed_groups) and biber carries neither, so biber is refused at the proxy before the agent API is reached.
PERSONA_BIBER_BLOCKED=true
SSO_SERVICE_ENABLED={{ lookup('config', application_id, 'services.sso.enabled') | string | lower }}
@@ -5,6 +5,8 @@ HOMEASSISTANT_BASE_URL={{ lookup('tls', application_id, 'url.base') | dotenv_quo
# nocheck: playwright-service-gate
MCP_SERVICE_ENABLED={{ lookup('config', application_id, 'mcp.enabled') | string | lower }}
# nocheck: persona-block-rationale: Home Assistant runs its own auth provider. The hub account is provisioned from secrets.credentials.administrator_password rather than the platform user password, and meta/services.yml pins sso.enabled false, so the administrator persona holds no credential the hub accepts.
PERSONA_ADMINISTRATOR_BLOCKED=true
# nocheck: persona-block-rationale: the deploy provisions only the hub administrator and the MCP service account in Home Assistant's own auth provider, and meta/services.yml pins sso.enabled false, so no auth path exists that would admit biber.
PERSONA_BIBER_BLOCKED=true
@@ -2,6 +2,8 @@ CANONICAL_DOMAIN={{ lookup('domain', application_id) | dotenv_quote }}
LITELLM_UI_BASE_URL={{ lookup('tls', application_id, 'url.base') | dotenv_quote }}
# nocheck: persona-block-rationale: the LiteLLM admin UI has no platform-user concept. It authenticates with the UI_USERNAME/UI_PASSWORD pair svc-ai-litellm provisions, and meta/services.yml pins sso.enabled false, so the administrator persona holds no credential the UI accepts (see TODO.md).
PERSONA_ADMINISTRATOR_BLOCKED=true
# nocheck: persona-block-rationale: the LiteLLM admin UI knows only the single UI_USERNAME account svc-ai-litellm provisions, and meta/services.yml pins sso.enabled false, so no auth path exists that would admit biber (see TODO.md).
PERSONA_BIBER_BLOCKED=true