# Secrets and configuration

Why an agent bundle never carries a credential, how the agent reaches external systems anyway, and where per-run configuration comes from.

An agent does not hold secrets. Model access, tool access, and identity are supplied by the
platform at run time, scoped to the tenant and the version, and recorded. What you ship is
behaviour and a contract; what the platform adds is authority.

- The deploy preflight excludes secret-looking files from the bundle and warns about them.
- Models are reached through the tenant's gateway with the platform's provider credentials.
- External tools are reached through governed connectors, whose credentials the platform holds.
- Per-run configuration comes from the run's `input` and the session's `agent_inputs`, both JSON
  your application controls.

## Nothing secret in the bundle

`tanomis agent deploy` flags `.env`, `*.pem`, `*.key`, and any file whose name contains
`credentials`, and excludes them from the package. The manifest never carries a secret either:
`mcp.connectors` references a connector by id, and the connector owns any credential reference.

If a credential was committed by mistake, rotate it; excluding it from the next bundle does not
undo the commit.

## How the agent reaches things

| Need | How it is supplied |
|---|---|
| A model | The tenant's LLM gateway, with the platform's provider credentials. You declare which models; you never see a provider key. |
| An external tool | A governed MCP connector. The connector's service credential, or a member's private connection, is presented at the gateway per call. |
| Another agent | A delegation, authorized per call by the control plane. |
| The platform's own APIs | A per-run identity assertion custodied outside the agent process. It authenticates the run to the platform; it is not an API key you can copy. |

An agent that needs an API the platform does not front should get it through a connector, so the
call is allowlisted, metered, and recorded, rather than by embedding a key.

## Configuration per run and per session

Your application passes configuration as data:

```json title="POST /v1/sessions"
{ "agent_name": "support-copilot", "agent_inputs": { "locale": "en-GB", "tone": "formal" } }
```

```json title="POST /v1/sessions/{session_id}/runs"
{ "input": { "prompt": "Draft a reply.", "case_id": "1842" } }
```

`agent_inputs` is session-scoped initialisation data; `input` is per run. Both reach your
entrypoint. Treat them as untrusted input and validate them; they are not a place for secrets
either, because they are stored with the session and visible in evidence at the tenant's capture
level.

## Environment-specific values

Do not branch on environment in code. The same version deploys to development and production
tenants; what differs is the tenant's policy, ceilings, and connectors. If behaviour must differ,
pass it through `agent_inputs` or ship a separate version.

## Where to go next

- [MCP connectors](/guides/connect-tools/mcp-connectors): how tool credentials are owned.
- [Choose models](/guides/build/choose-models): the gateway.
- [Identity and access](/concepts/identity-and-access): the run identity the platform supplies.