Scoped SSO permission set so laptop agents stop running as AdministratorAccess #302

New issue

Open

opened 2026-06-12 08:06:45 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-12 08:06:45 +00:00

Owner

Finding from the 2026-06-11/12 SSM audit (agentic-os-kai#655): laptop Claude/agent sessions run as the AWSReservedSSO_AdministratorAccess role - the same principal as Kai herself. Consequence: the alias/admin-only CMK (description: "Wraps SSM params under /<>/admin/ paths") cannot distinguish an agent from Kai, so the admin tier currently only protects against the fleet machine users (kai-server, kai-server-k3s, ser8, which have ssm:*Parameter* and no kms: actions).

Two candidate fixes, not mutually exclusive:

Scoped SSO permission set for agent sessions - a second permission set (e.g. AgentAccess) granting the day-to-day surface (ssm get/put on non-admin paths, the usual service APIs) but excluding kms:Decrypt on the admin-only key. Agent harnesses log in with the scoped profile, Kai keeps AdministratorAccess for herself. Open question: ergonomics of two SSO profiles on one laptop (AWS_PROFILE per session vs per-tool default).
coily lockdown path deny - coily policy rule denying aws ssm get-parameter --with-decryption when the name matches */admin/*. Works today regardless of IAM, ships with the existing lockdown machinery, but only binds agents routed through coily (defense in depth, not a boundary by itself - the harness allowlist already forces coily routing, so in practice it covers the agent path).

Context: the audit shrank the admin-tier candidate set to near zero because most secrets are agent- or cluster-consumed, but the tier becomes meaningful the moment laptop agents stop being account admins.

Finding from the 2026-06-11/12 SSM audit (agentic-os-kai#655): laptop Claude/agent sessions run as the `AWSReservedSSO_AdministratorAccess` role - the same principal as Kai herself. Consequence: the `alias/admin-only` CMK (description: "Wraps SSM params under /<*>/admin/* paths") cannot distinguish an agent from Kai, so the admin tier currently only protects against the fleet machine users (`kai-server`, `kai-server-k3s`, `ser8`, which have `ssm:*Parameter*` and no `kms:` actions). Two candidate fixes, not mutually exclusive: 1. **Scoped SSO permission set for agent sessions** - a second permission set (e.g. `AgentAccess`) granting the day-to-day surface (ssm get/put on non-admin paths, the usual service APIs) but excluding `kms:Decrypt` on the admin-only key. Agent harnesses log in with the scoped profile, Kai keeps AdministratorAccess for herself. Open question: ergonomics of two SSO profiles on one laptop (AWS_PROFILE per session vs per-tool default). 2. **coily lockdown path deny** - coily policy rule denying `aws ssm get-parameter --with-decryption` when the name matches `*/admin/*`. Works today regardless of IAM, ships with the existing lockdown machinery, but only binds agents routed through coily (defense in depth, not a boundary by itself - the harness allowlist already forces coily routing, so in practice it covers the agent path). Context: the audit shrank the admin-tier candidate set to near zero because most secrets are agent- or cluster-consumed, but the tier becomes meaningful the moment laptop agents stop being account admins.

coilysiren added the

label

2026-06-17 07:06:32 +00:00

coilysiren added the

interactive

label

2026-06-18 06:26:01 +00:00