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.