Credential Broker

Faramesh does not store credentials. Instead, it brokers access to your existing secrets manager. When a connector needs to execute, Faramesh fetches the credential from your infrastructure, injects it ephemerally into the execution, and it's gone when the action completes.

We work with what you already have. Enterprise buyers ask "Does it work with our Vault?" before "How does it work?" Faramesh integrates with:

Security model: workload identity, nothing credential-shaped in the DB

If per-tenant config stored auth material (tokens, access keys, JWT secrets), breaching Faramesh’s DB would give an attacker keys to every customer’s secrets manager. One breach, every customer’s credential infrastructure exposed.

Faramesh avoids that entirely. Per-tenant configuration in the database contains only connection metadata — never auth material.

Authentication at runtime:

• HashiCorp Vault: Faramesh authenticates using a short-lived, cryptographically attested workload identity — e.g. a SPIFFE SVID (JWT) issued at runtime. Customer enables JWT auth in Vault and trusts Faramesh’s JWKS. Faramesh presents the JWT; Vault validates the signature. Nothing credential-shaped is stored; the SVID expires in minutes.

• AWS Secrets Manager: Faramesh’s server runs with an IAM role (e.g. on EC2/ECS/EKS). No stored AWS credentials. At runtime, for a customer that configured their role ARN and ExternalId, Faramesh calls STS AssumeRole (cross-account) with that ExternalId. The customer’s role trust policy must require the same ExternalId (confused deputy prevention); otherwise any principal that learns the ARN could assume the role. AWS returns 15-minute temporary credentials; Faramesh fetches the secret; credentials expire. A DB breach yields only role ARNs and ExternalIds — useless without Faramesh’s own AWS identity.

• Azure Key Vault: Customer creates an app registration (or managed identity) and adds a federated credential that trusts Faramesh’s OIDC issuer. Faramesh requests a short-lived token from Azure AD and uses it to read Key Vault. No client secret in Faramesh’s DB. See Azure Key Vault — Federated credential below.

• Doppler, 1Password: Federated or short-lived tokens (service tokens, OIDC, or injectors). No long-lived secrets stored in Faramesh’s DB. See their setup sections below.

The only crown jewels Faramesh must protect: its own signing keys (e.g. for SPIFFE) and its own cloud identity (e.g. the IAM role). Those need HSM-backed storage, rotation, and the highest security bar. Customer auth material is never in Faramesh’s database.

• HashiCorp Vault

• AWS Secrets Manager

• Azure Key Vault

• 1Password Business (via 1Password Connect)

• Doppler

No rip-and-replace. Your security team trusts these systems—they're already audited and in your compliance scope. Faramesh is the layer that decides who gets momentary access; your secrets manager holds the credentials. The broker includes a comprehensive test suite covering all three main backends (Vault, AWS Secrets Manager, Azure Key Vault) and connector wiring. When a secret is missing, error messages include the exact secret path to speed up debugging. For Vault, SPIFFE/Vault JWT auth is documented for workload identity (see SPIFFE/SPIRE Integration below).

How It Works

1. Agent requests a connector action (e.g. Stripe refund)

2. Faramesh evaluates policy: should this action execute?

3. If allowed, Faramesh fetches the credential from your secrets manager

4. Credential is injected into the connector for this execution only

5. Action runs

6. Credential is discarded—never stored in Faramesh

Faramesh never touches your crown jewels. It only decides who gets momentary access.

Per-tenant configuration (UI and API)

Each organization (tenant) can choose its own secrets manager and provide connection metadata only (no tokens or keys).

• Dashboard: Integrations → Configure next to “Secrets manager”. Select backend (Vault, AWS Secrets Manager, Azure Key Vault, Doppler, 1Password, or Environment variables) and optionally fill metadata (Vault URL, role name, path prefix; AWS role ARN; etc.). Saved data is metadata only; auth uses workload identity at runtime.

• API:

  • GET /v1/connectors/credential-backend — returns current backend and label for the tenant (uses X-Tenant-ID).

  • PUT /v1/connectors/credential-backend — body { "backend": "vault" | "aws_secrets" | "azure_keyvault" | "onepassword" | "doppler" | "env" }. Requires X-Tenant-ID.

  • GET /v1/connectors/credential-backend/config — returns per-tenant connection metadata (URLs, role names, path prefixes, role ARNs). No secrets.

  • PUT /v1/connectors/credential-backend/config — body: optional keys such as vault_addr, vault_role, path_prefix, aws_role_arn, aws_external_id (required for AWS cross-account; see below), aws_region, azure_vault_url, doppler_project, doppler_config, onepassword_connect_host, onepassword_vault_id. Only these keys are accepted; any secret-like key is rejected. Requires X-Tenant-ID.

Stored metadata is used at credential fetch time: the broker builds the backend (e.g. Vault, AWS) using per-tenant metadata when present, so the customer’s Vault URL, path prefix, AWS region, etc. come from the DB without any credentials.

Global fallback: if no per-tenant backend is set, Faramesh uses the deployment’s FARA_CREDENTIAL_BACKEND (and related env vars) for that tenant.

Federated trust setup (customer side)

You must configure your side of the trust relationship. Faramesh never stores tokens or keys; it authenticates at runtime using workload identity. The steps below are what your team does in your Vault, AWS, Azure, Doppler, or 1Password so that only Faramesh (and only in the intended way) can access your secrets. Do this before or during your first pilot—otherwise credential fetch will fail and you’ll lose time debugging.

HashiCorp Vault — JWT auth trusting Faramesh’s JWKS

Goal: Your Vault accepts a short-lived JWT from Faramesh (e.g. SPIFFE SVID) and issues a Vault token. No static Vault token is ever stored in Faramesh.

1. Enable the JWT auth method (if not already):

   
   

   
   

2. Configure the JWT auth method to use Faramesh’s JWKS endpoint so Vault can verify the JWT signature:

   • Faramesh exposes a JWKS URL (e.g. https://<faramesh-host>/.well-known/jwks.json or your SPIFFE trust domain’s JWKS). Obtain this from your Faramesh deployment or support.

   • In Vault:

     
     

     vault write auth/jwt/config \
       oidc_discovery_url="https://<faramesh-jwks-or-oidc-url>" \
       bound_issuer="https://<faramesh-issuer>"

     vault write auth/jwt/config \
       oidc_discovery_url="https://<faramesh-jwks-or-oidc-url>" \
       bound_issuer="https://<faramesh-issuer>"

     vault write auth/jwt/config \
       oidc_discovery_url="https://<faramesh-jwks-or-oidc-url>" \
       bound_issuer="https://<faramesh-issuer>"

     Or if using raw JWKS:

     
     

     vault write auth/jwt/config \
       jwks_url="https://<faramesh-host>/.well-known/jwks.json" \
       bound_issuer="<issuer-from-faramesh>"

     vault write auth/jwt/config \
       jwks_url="https://<faramesh-host>/.well-known/jwks.json" \
       bound_issuer="<issuer-from-faramesh>"

     vault write auth/jwt/config \
       jwks_url="https://<faramesh-host>/.well-known/jwks.json" \
       bound_issuer="<issuer-from-faramesh>"

     
     

3. Create a role that maps the JWT to a policy that can read your KV secrets (e.g. path secret/data/faramesh/*):

   
   

   vault write auth/jwt/role/faramesh \
     role_type="jwt" \
     bound_audiences="<audience-if-any>" \
     user_claim="sub" \
     bound_subject="<optional-sub-pattern>" \
     policies="faramesh-read"

   vault write auth/jwt/role/faramesh \
     role_type="jwt" \
     bound_audiences="<audience-if-any>" \
     user_claim="sub" \
     bound_subject="<optional-sub-pattern>" \
     policies="faramesh-read"

   vault write auth/jwt/role/faramesh \
     role_type="jwt" \
     bound_audiences="<audience-if-any>" \
     user_claim="sub" \
     bound_subject="<optional-sub-pattern>" \
     policies="faramesh-read"

   
   

   Create policy faramesh-read with capability read on the KV path prefix you use (e.g. secret/data/faramesh/*).

4. In Faramesh (UI or API): Set backend to Vault, and set Vault URL, JWT role name (e.g. faramesh), and path prefix (e.g. faramesh). Do not put a Vault token anywhere; Faramesh will present the JWT and get a token at runtime.

If you skip this: You will be forced to put a static Vault token in env or in the DB, which brings back the crown-jewels risk. The federated path is the only safe pattern.

AWS Secrets Manager — Cross-account role with ExternalId (required)

Goal: Faramesh (running in its own AWS account with an IAM role) calls STS AssumeRole to assume a customer-created role in your account. That role has permission to read Secrets Manager. ExternalId is mandatory so that only Faramesh can assume the role (confused deputy prevention).

Without ExternalId: Any AWS principal (in any account) that learns your role ARN could add it to their trust policy and assume your role. Storing only the role ARN in Faramesh’s DB is not enough—you must scope the trust to Faramesh using ExternalId.

1. Create an IAM role in your AWS account (e.g. faramesh-access) that will be assumed by Faramesh.

2. Trust policy for this role must:

   • Set the principal to Faramesh’s AWS account (or a specific role in that account). Example: arn:aws:iam::FARAMESH_ACCOUNT_ID:root or arn:aws:iam::FARAMESH_ACCOUNT_ID:role/faramesh-broker.

   • Include a condition that requires sts:ExternalId with a value that only you and Faramesh know (e.g. a UUID or faramesh-<tenant-id>). Faramesh will send this value when calling AssumeRole; AWS will reject the call if it doesn’t match.

   Example trust policy:

   
   

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::FARAMESH_ACCOUNT_ID:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "your-chosen-external-id-here"
           }
         }
       }
     ]
   }

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::FARAMESH_ACCOUNT_ID:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "your-chosen-external-id-here"
           }
         }
       }
     ]
   }

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::FARAMESH_ACCOUNT_ID:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "your-chosen-external-id-here"
           }
         }
       }
     ]
   }

   
   

   Replace FARAMESH_ACCOUNT_ID with the account ID Faramesh runs in (obtain from your Faramesh admin). Replace your-chosen-external-id-here with a secret value you choose (e.g. from a UUID generator).

3. Attach a policy to the role that allows reading secrets (e.g. secretsmanager:GetSecretValue) for the resource prefix you use (e.g. arn:aws:secretsmanager:region:account:secret:faramesh/*).

4. In Faramesh (UI or API): Set backend to AWS Secrets Manager. Set Customer IAM role ARN to the role’s ARN (e.g. arn:aws:iam::YOUR_ACCOUNT_ID:role/faramesh-access) and External ID to the exact same value you put in the trust policy. Set region and secrets prefix as needed.

At runtime, Faramesh calls AssumeRole(RoleArn=<your-role-arn>, ExternalId=<your-external-id>). If ExternalId is missing or wrong, AWS denies the call. One field, non-negotiable.

Azure Key Vault — Federated credential (workload identity)

Goal: Faramesh does not store an Azure client secret or password. It uses workload identity / federated credential: your Azure tenant trusts Faramesh’s OIDC issuer and grants a token to Faramesh’s identity when it presents the right claim.

Runtime auth (explicit): Faramesh’s server runs with an Azure identity (e.g. app registration with federated credential, or managed identity). When a customer configures Azure Key Vault, Faramesh uses cross-tenant or customer-specific federated credential: your Azure app registration (or user-assigned identity) has a federated credential that trusts Faramesh’s issuer (e.g. https://<faramesh>/oidc or the Azure AD issuer where Faramesh runs). When Faramesh needs to read your Key Vault, it requests a token for your tenant using that federated credential; Azure AD validates the trust and issues a short-lived token. No client secret is stored anywhere.

Customer steps (high level):

1. Create an App Registration in your Azure AD (or use a user-assigned managed identity).

2. Add a federated credential on that app (or identity):

   • Issuer: Faramesh’s OIDC issuer URL (from your Faramesh deployment).

   • Subject/audience: the value Faramesh will send (e.g. its own client ID or a tenant-specific identifier).

3. Grant the app (or identity) access to your Key Vault: Key Vault → Access control → Add role assignment → Key Vault Secrets User (or custom) for this app/identity.

4. In Faramesh: Set Azure Key Vault URL and secret prefix. No client ID or secret are stored; Faramesh uses the federated trust at runtime.

If your Faramesh deployment does not yet expose an OIDC issuer for Azure, use DefaultAzureCredential in the same tenant (e.g. Faramesh runs in your Azure and uses managed identity). For cross-tenant, the federated credential path above is required and must be implemented on the Faramesh side and documented with the exact issuer URL and claim format.

Doppler — Federated or short-lived tokens

Goal: Avoid storing a long-lived Doppler token in Faramesh’s environment. Prefer a federated or short-lived pattern so a DB or env breach does not expose access to all of Doppler.

Options:

1. Service tokens (Doppler): Create a Doppler service token with the minimum project/config and scope needed. Use a short validity if Doppler supports it, and rotate regularly. Store it in a secure runtime source (e.g. secret injected at deploy time from a vault), not in Faramesh’s DB. This is still a secret in one place but scoped and rotatable.

2. OIDC / SSO (if supported): If Doppler supports OIDC or SAML for machine access, configure it so Faramesh (or the runtime where Faramesh runs) can obtain a short-lived token via your IdP. Then no long-lived Doppler token exists.

3. In Faramesh: Set backend to Doppler and set project, config, and secret prefix. The actual token for Doppler API access must come from workload identity or a short-lived mechanism above—not from a field in Faramesh’s UI (we do not store tokens). Document in your runbook how the Doppler token is supplied at runtime (e.g. env var from a secure injector that uses OIDC).

1Password Connect — Federated or scoped tokens

Goal: Faramesh talks to your 1Password Connect server without a long-lived token stored in Faramesh’s DB or config.

Options:

1. 1Password Connect with short-lived / scoped token: Use a dedicated access token for 1Password Connect with minimal scope (e.g. only the vaults and items needed). Rotate it regularly. Supply it at runtime via workload identity or a secret injector (e.g. from Vault or your IdP), not via Faramesh’s per-tenant config (we only store host and vault ID).

2. OIDC / SCIM (if available): If 1Password supports OIDC or machine-to-machine auth, configure it so the token is short-lived and obtained at runtime.

3. In Faramesh: Set 1Password Connect host and Vault ID. The token used to call the Connect API must be provided at runtime (e.g. FARA_1PASSWORD_CONNECT_TOKEN from a secure source). We do not store it in the DB; the federated or injector pattern keeps it out of Faramesh’s persistent config.

Connect Your Secrets Manager

One integration per customer—your HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password Business, or Doppler account—instead of configuring each connector separately. Prefer workload identity (SPIFFE, IAM role) over static tokens; use env vars only for development or for Faramesh’s own identity.

HashiCorp Vault

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_TOKEN="your-vault-token"
export FARA_VAULT_MOUNT="secret"
export FARA_VAULT_PATH_PREFIX="faramesh"

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_TOKEN="your-vault-token"
export FARA_VAULT_MOUNT="secret"
export FARA_VAULT_PATH_PREFIX="faramesh"

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_TOKEN="your-vault-token"
export FARA_VAULT_MOUNT="secret"
export FARA_VAULT_PATH_PREFIX="faramesh"

Store connector credentials in Vault at paths like:

• secret/data/faramesh/stripe — {"api_key": "sk_..."}

• secret/data/faramesh/github — {"token": "ghp_..."}

• secret/data/faramesh/aws — {"access_key_id": "...", "secret_access_key": "...", "region": "us-east-1"}

Install the Vault optional dependency:

AWS Secrets Manager

Cross-account (recommended): Use the AWS federated trust setup above. In Faramesh store: Customer IAM role ARN, External ID (must match the trust policy condition), region, and secrets prefix. No access keys; Faramesh uses STS AssumeRole with ExternalId.

Same-account (Faramesh and secrets in one AWS account): Uses the default AWS credential chain (IAM role, env vars). Env only for deployment-level config:

export FARA_CREDENTIAL_BACKEND=aws_secrets
export FARA_AWS_REGION="us-east-1"
export FARA_AWS_SECRETS_PREFIX="faramesh/"

export FARA_CREDENTIAL_BACKEND=aws_secrets
export FARA_AWS_REGION="us-east-1"
export FARA_AWS_SECRETS_PREFIX="faramesh/"

export FARA_CREDENTIAL_BACKEND=aws_secrets
export FARA_AWS_REGION="us-east-1"
export FARA_AWS_SECRETS_PREFIX="faramesh/"

Store connector credentials as secrets:

• faramesh/stripe — JSON: {"api_key": "sk_..."}

• faramesh/github — JSON: {"token": "ghp_..."}

Azure Key Vault

Runtime auth: Faramesh uses workload identity / federated credential. You create an app registration (or managed identity) in your tenant, add a federated credential that trusts Faramesh’s OIDC issuer, and grant that identity access to your Key Vault. Faramesh then requests a short-lived token and reads secrets—no client secret stored. See Azure Key Vault — Federated credential above.

Same-tenant (Faramesh runs in your Azure): Can use DefaultAzureCredential (managed identity, env vars, Azure CLI). Env for deployment-level config:

export FARA_CREDENTIAL_BACKEND=azure_keyvault
export FARA_AZURE_KEYVAULT_URL="https://myvault.vault.azure.net/"
export FARA_AZURE_SECRET_PREFIX="faramesh-"

export FARA_CREDENTIAL_BACKEND=azure_keyvault
export FARA_AZURE_KEYVAULT_URL="https://myvault.vault.azure.net/"
export FARA_AZURE_SECRET_PREFIX="faramesh-"

export FARA_CREDENTIAL_BACKEND=azure_keyvault
export FARA_AZURE_KEYVAULT_URL="https://myvault.vault.azure.net/"
export FARA_AZURE_SECRET_PREFIX="faramesh-"

Store connector credentials as secrets (JSON value):

• faramesh-stripe — {"api_key": "sk_..."}

• faramesh-github — {"token": "ghp_..."}

• For multi-tenant: faramesh-{tenant_id}-stripe

Install the Azure optional dependency:

1Password Business (1Password Connect)

Use 1Password Connect Server so Faramesh can fetch connector credentials from your 1Password vaults. Federated / short-lived: Prefer a scoped or rotated token supplied at runtime (e.g. from your IdP or vault), not a long-lived token in env. See 1Password Connect — Federated or scoped tokens above.

For deployment-level config (host and vault ID only; token from secure runtime source):

export FARA_CREDENTIAL_BACKEND=onepassword
export FARA_1PASSWORD_CONNECT_HOST="https://your-connect-server.com"
export FARA_1PASSWORD_CONNECT_TOKEN="<from-secure-runtime-source>"
export FARA_1PASSWORD_VAULT_ID="your-vault-uuid"

export FARA_CREDENTIAL_BACKEND=onepassword
export FARA_1PASSWORD_CONNECT_HOST="https://your-connect-server.com"
export FARA_1PASSWORD_CONNECT_TOKEN="<from-secure-runtime-source>"
export FARA_1PASSWORD_VAULT_ID="your-vault-uuid"

export FARA_CREDENTIAL_BACKEND=onepassword
export FARA_1PASSWORD_CONNECT_HOST="https://your-connect-server.com"
export FARA_1PASSWORD_CONNECT_TOKEN="<from-secure-runtime-source>"
export FARA_1PASSWORD_VAULT_ID="your-vault-uuid"

Create one 1Password item per connector; use the title as the connector name (e.g. stripe, github). Put each credential in a field whose label matches the key (e.g. label API Key for Stripe’s api_key). Alternatively, use a single field with label credentials and value = JSON object (e.g. {"api_key": "sk_..."}).

Multi-tenant: use item title tenant_123_stripe for path tenant_123/stripe.

Doppler

Doppler centralizes secrets across teams and environments. Federated or short-lived tokens: Avoid a long-lived Doppler token in env; use service tokens with minimal scope and rotation, or OIDC if supported. See Doppler — Federated or short-lived tokens above.

export FARA_CREDENTIAL_BACKEND=doppler
export FARA_DOPPLER_TOKEN="<short-lived-or-from-injector>"
export FARA_DOPPLER_PROJECT="your-project"
export FARA_DOPPLER_CONFIG="prd"
export FARA_DOPPLER_SECRET_PREFIX="FARAMESH_"

export FARA_CREDENTIAL_BACKEND=doppler
export FARA_DOPPLER_TOKEN="<short-lived-or-from-injector>"
export FARA_DOPPLER_PROJECT="your-project"
export FARA_DOPPLER_CONFIG="prd"
export FARA_DOPPLER_SECRET_PREFIX="FARAMESH_"

export FARA_CREDENTIAL_BACKEND=doppler
export FARA_DOPPLER_TOKEN="<short-lived-or-from-injector>"
export FARA_DOPPLER_PROJECT="your-project"
export FARA_DOPPLER_CONFIG="prd"
export FARA_DOPPLER_SECRET_PREFIX="FARAMESH_"

Store one secret per connector: name FARAMESH_STRIPE, value = JSON string {"api_key": "sk_..."}. For multi-tenant, use name FARAMESH_TENANT_123_STRIPE.

SPIFFE/SPIRE Integration (Vault JWT auth)

Faramesh supports Vault JWT authentication so you can use a SPIFFE-issued SVID (or any JWT) to obtain a Vault token—no static FARA_VAULT_TOKEN required.

Option A: JWT in env (e.g. from sidecar)

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_JWT="<your-spiffe-jwt>"
export FARA_VAULT_JWT_ROLE="faramesh"

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_JWT="<your-spiffe-jwt>"
export FARA_VAULT_JWT_ROLE="faramesh"

export FARA_CREDENTIAL_BACKEND=vault
export FARA_VAULT_ADDR="https://vault.example.com"
export FARA_VAULT_JWT="<your-spiffe-jwt>"
export FARA_VAULT_JWT_ROLE="faramesh"

Option B: JWT from file (e.g. SPIRE socket or mounted SVID)

export FARA_VAULT_JWT_PATH="/run/spire/svid/jwt/svid.jwt"
export FARA_VAULT_JWT_ROLE="faramesh"

export FARA_VAULT_JWT_PATH="/run/spire/svid/jwt/svid.jwt"
export FARA_VAULT_JWT_ROLE="faramesh"

export FARA_VAULT_JWT_PATH="/run/spire/svid/jwt/svid.jwt"
export FARA_VAULT_JWT_ROLE="faramesh"

Configure Vault's JWT auth method with your SPIFFE trust domain (JWKS or OIDC). Faramesh calls auth/jwt/login with the JWT and uses the returned token for KV reads. This aligns with NIST's AI Agent Standards Initiative (2026) and keeps workload identity in SPIFFE/SPIRE.

Legacy Mode (Environment Variables)

If FARA_CREDENTIAL_BACKEND is unset or env, Faramesh uses the previous behavior: credentials from environment variables (FARA_STRIPE_API_KEY, etc.) or settings. This remains supported for development and simple deployments.

Multi-Tenant Paths

For multi-tenant deployments, include the tenant ID in the path:

• Vault: faramesh/{tenant_id}/stripe

• AWS: faramesh/{tenant_id}/stripe

• Azure Key Vault: faramesh-{tenant_id}-stripe

• 1Password: item title {tenant_id}_stripe

• Doppler: secret name FARAMESH_{tenant_id}_STRIPE

Policy: credential access

You can allow or deny credential access per agent or connector. When the broker is enabled, Faramesh evaluates a policy with operation: credential_access before fetching from your secrets manager. Add rules that match credential_access to restrict which agents can use which connector credentials:

rules:
  - match:
      tool: stripe
      operation: credential_access
      agent_id: agent-prod-*
    allow: true
  - match:
      tool: stripe
      operation: credential_access
    deny: true
    reason: "Only prod agents may use Stripe credentials"

rules:
  - match:
      tool: stripe
      operation: credential_access
      agent_id: agent-prod-*
    allow: true
  - match:
      tool: stripe
      operation: credential_access
    deny: true
    reason: "Only prod agents may use Stripe credentials"

rules:
  - match:
      tool: stripe
      operation: credential_access
      agent_id: agent-prod-*
    allow: true
  - match:
      tool: stripe
      operation: credential_access
    deny: true
    reason: "Only prod agents may use Stripe credentials"

If no rule matches credential_access, access is allowed (backward compatible). Only explicit deny rules block credential fetch.

Security

• No credentials in the DB: Per-tenant config stores only connection metadata (URLs, role names, path prefixes, role ARNs, ExternalId for AWS). Tokens, keys, and secrets are never stored.

• Workload identity at runtime: Vault (SPIFFE/JWT), AWS (IAM role + STS AssumeRole with ExternalId), Azure (federated credential), Doppler/1Password (federated or short-lived tokens). Auth happens at fetch time; nothing to steal from Faramesh’s DB.

• ExternalId (AWS) is non-negotiable: Without it, any AWS principal that discovers a customer’s role ARN could assume that role (confused deputy). The customer’s trust policy must require sts:ExternalId; Faramesh passes the same value on AssumeRole. One field, must be there.

• Credentials exist only in memory during execution and are discarded after use.

• Your secrets manager remains the single source of truth; Faramesh’s job is the authorization decision and ephemeral brokering—not credential storage.