mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-23 09:07:46 +02:00
DottaandPaperclip
bf3c7b08c4
listAgentSecretAccess grouped an agent's bindings by the underlying secretId and always reported company_secrets.key, so an approved access.<ALIAS> grant was listed under the managed secret's own key and several aliases over one reused secret collapsed into a single entry. An API-only alias on a shared managed secret was therefore unreachable from a governed run. Project each binding under the key an agent actually addresses it by instead: env.* keeps projecting the managed secret key, access.<ALIAS> projects the alias, normalized the same way managed keys are. Grouping by (secretId, projected key) keeps distinct aliases separate while an alias equal to its secret's key still merges with the env grant into a single delivery: "both" entry. Selection within a group prefers the API binding, so POST /api/agents/me/secrets/:key/value resolves the exact projected binding; all run-bound authorization, audit, and redaction checks are unchanged. Covered by service, route, and end-to-end route tests for a mismatched managed key vs alias, two aliases over one secret, and the env/API pair that shares a projected key. Tests use fixtures only. Co-Authored-By: Paperclip <noreply@paperclip.ing>