feat: hierarchical agent credentials and per-intent CLI selection - #405
feat: hierarchical agent credentials and per-intent CLI selection#405JWThewes wants to merge 9 commits into
Conversation
| } | ||
| if (binding) bindings = [binding]; | ||
| } else { | ||
| const requestedCli = payload.requestedCli || meta?.agentCli || null; |
There was a problem hiding this comment.
for discussion-assist-start on a DRAFT intent, payload does not contain requestedCli and meta.agentCli is still null. Therefore, no credentials are resolved, availableClis is empty, and the assistant fails. Could we pass and resolve the user’s selected CLI and credential binding for this command, and add a test for this scenario?
|
Please also update documentation (at least |
| /> | ||
| } | ||
| description="Which AI agent CLI runs this space's work — only CLIs installed in the deployment are selectable." | ||
| description="Highlighted when a user chooses a CLI for an intent; each user still makes an explicit selection." |
There was a problem hiding this comment.
strange description, looks super generic and not targeting the user, more like a comment
| import { SecretField } from '@/components/settings/SecretField'; | ||
| import { SaveStatusButton, type SaveResult } from '@/components/settings/SaveStatusButton'; | ||
|
|
||
| type Scope = 'platform' | 'space' | 'personal'; |
There was a problem hiding this comment.
Wondering why we don't have the intent scope. As of now the intent binds to the selected scope, but if we want to create a dedicated api key for one intent ?
| "arn:${local.partition}:ssm:${data.aws_region.current.region}:${data.aws_caller_identity.current.account_id}:parameter/${var.project_name}/${var.environment}/users/*/agent-credentials/*", | ||
| "arn:${local.partition}:ssm:${data.aws_region.current.region}:${data.aws_caller_identity.current.account_id}:parameter/${var.project_name}/${var.environment}/projects/*/agent-credentials/*", |
There was a problem hiding this comment.
This resource is correctly limited to the current application and environment, but the wildcards still allow the shared AgentCore role to decrypt every user and space credential in that deployment. AgentCore also has permission to scan execution metadata containing credential bindings, so these paths are discoverable. Could credential lookup be moved behind the existing broker pattern, so AgentCore can request only the binding authorized for the current invocation? (AgentCore -> agent-credential broker -> SSM)
|
@jeromevdl addressed your comments |
| missingCredentialBindings.push(credentialBinding); | ||
| continue; | ||
| } | ||
| invocationEnv[credentialEnvName(binding.provider)] = value; |
There was a problem hiding this comment.
This PR necessarily passes credentials through the CLI environment. Output redaction should be handled separately and consistently for both agent credentials and MCP environment variables. I’ll track application-level redaction and CloudWatch data-protection policies in a follow-up issue: #406
Not sure everything was addressed... Please mark resolved the comments you have fixed. |
2 participants
Summary
user > space > platformprecedenceTesting
Closes #404