Credential boundaries for production AI agents

Most useful agents eventually need access to something private: a repository, a ticket queue, a database, an internal API, or a model provider. The question is not whether credentials exist. The question is whether the runtime can use them without turning them into model-visible text.

Facio treats credentials as runtime-owned values. The agent can refer to placeholders, Placet can collect secret fields, and the runtime resolves the value only at the boundary where a tool or provider needs it.

Do not paste secrets into work instructions

Secrets in prompts become hard to control. They can appear in history, logs, tool output, model context, screenshots, or follow-up messages. Even when a model does not intentionally reveal them, downstream tooling may persist more than expected.

Use credential storage instead. A workflow should say, for example, that an MCP server uses ${credentials.GITHUB_TOKEN}, not the raw token.

Separate three boundaries

Boundary	What it controls	Production default
Provider credentials	Model API access and OAuth state	Managed by provider settings or OAuth flow
Tool credentials	MCP headers, stdio env, internal APIs	Placeholder references resolved by runtime
Shell exposure	Environment variables available to commands	Empty unless a CLI explicitly needs one

Those boundaries should not collapse into one global secret bag. A GitHub token used by an MCP server does not automatically need to appear in shell commands. A provider key used for model routing does not need to appear in a task transcript.

Review broad scopes

Credential scope determines what an agent could do after a mistake. Read-only tokens, project-scoped access, short-lived credentials, and service accounts with narrow permissions make review much easier. Broad personal tokens make every workflow harder to reason about.

The strongest deployment posture is boring: scoped credentials, visible placeholders, no secrets in prompts, and review before side effects.