Providers supported

The agent's ResolverByType dispatches to one resolver per target_provider_type string. The CP's metadata layer is provider- agnostic — every provider implements the same core.Provider interface.

target_provider_type	Resolver status	Auth options	Config keys
vault	✅ ships	Token (SB_VAULT_TOKEN) or Kubernetes (SB_VAULT_KUBERNETES_ROLE)	address, kvMount (default secret), kvPrefix, namespace
aws-sm	✅ ships	Standard AWS SDK chain (IRSA / instance role / AWS_* env / shared profile)	region (required), roleArn (cross-account), endpoint (LocalStack)
gcp-sm	placeholder	—	—
azure-kv	placeholder	—	—
kubernetes	placeholder	—	—

HashiCorp Vault

KV v2 only. Path layout depends on the kvMount config (default secret). The agent reads via {mount}/data/{ref} and writes the KV v2 {"data": {...}} envelope.

Authentication

Method	Required env	When
Token	SB_VAULT_TOKEN	Local dev, dev profile in docker-compose (vault dev)
Kubernetes	SB_VAULT_KUBERNETES_ROLE	Production on K8s — uses the projected SA token, lease-tracked + refresh

The token method auto-renews within tokenRefreshMargin = 30s of expiry. The Kubernetes method re-authenticates from the SA token on lease expiry.

Refused payload keys

The Vault resolver refuses these keys in the request's target_provider_config (defends against an api PR that accidentally tries to ship credentials):

• token

A future PR will refuse more.

Tag preservation

Vault custom_metadata is surfaced verbatim into the CP's secrets.labels jsonb on discovery — so a Team: billing tag in Vault becomes a filterable label in the UI's Secrets page.

AWS Secrets Manager

The agent uses the AWS SDK Go v2 client. All credential resolution goes through the standard SDK chain — no new credential env vars are introduced. This is deliberate: adding SB_AWS_*_KEY would duplicate the chain and invite operators to mix sources.

Authentication

Method	What
IRSA	Recommended for EKS deployments
Instance role	EC2 / Fargate
AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY	Local dev / non-AWS hosts
Shared profile (~/.aws/credentials)	Developer machine

Cross-account access via SB_AWS_ROLE_ARN triggers an AssumeRole through STS.

Refused payload keys

The AWS SM resolver refuses seven credential-shaped keys in the request's target_provider_config (table-driven check):

awsAccessKeyID awsSecretAccessKey awsSessionToken accessKeyID secretAccessKey sessionToken credentials

Tag preservation

AWS Tags are surfaced as labels on discovery — same pattern as Vault custom_metadata.

What "supported" actually means

A provider ships when three things are true:

1. The core.Provider interface is implemented in core/providers/<kind>
2. The agent's ResolverByType registers the kind
3. There's a live e2e against a real instance of the provider (or LocalStack) — verified plaintext round-trip end-to-end, canary scan returns zero matches

GCP SM, Azure Key Vault, and Kubernetes Secret are at step (1) partially — the metadata interface stubs are written; the resolver + e2e land per design partner request.

Adding a new provider

The pattern is established. The next provider lands as:

1. New package core/providers/<kind>/<kind>.go implementing Provider. Take the SDK client as an interface (subset interface so unit tests inject a fake).
2. Register(*providers.Registry) function — no init().
3. Unit tests in <kind>_test.go covering: registration, pagination if applicable, NotFound mapping to providers.ErrNotFound, no-leak assertion on error messages.
4. Agent: add to internal/executor/resolvers.go under ResolverByType. Refuse credential-shaped keys in the payload.
5. Live e2e: bring up a real (or LocalStack) instance, mint an agent, submit a patch + read, verify round-trip.
6. Open one PR per repo (core for the connector, agent for the resolver). Cross-link them.