AWS Secrets Manager is the production source for provider tokens and other sensitive runtime configuration. Local development uses ignored environment files.
How Harmonia uses it
CDK grants each runtime IAM role access only to its required named secrets and injects those secrets into ECS Fargate tasks or AgentCore Runtime as environment variables. Examples include internal service authentication, Telegram credentials, X credentials, OAuth secrets, and upload-scanner authorization.
Security and authority
Secrets stay server-side and are excluded from Git, browser responses, prompts, AgentCore Memory, traces, logs, replay bundles, and public evidence. Access to a credential does not authorize an effect; approval and policy still bind the exact action.
Failure behavior
Missing required secrets fail configuration or provider calls visibly. Harmonia does not substitute placeholder credentials or mark an unauthenticated integration as connected.
Rotation
Generated internal service tokens use retained, encrypted Secrets Manager secrets. Rotate them only through How to rotate internal service tokens, which requires separate spending and rotation approvals before it can call AWS. Provider OAuth credentials follow the provider’s own reconnect flow; the connection-envelope key requires a deliberate data-migration procedure.
Evidence status
Configuration validation and deployment wiring are repository-verified. Production secret use requires redacted configuration and IAM evidence; secret values themselves must never be captured.
Relevant files
src/lib/config.tsagent/harmonia_agent/config.pyinfra/setup.shinfra/deploy.shinfra/rotate-service-secrets.shdocs/configuration.mdx
Last modified on September 14, 2026
