Security

Credentials

• Connection secrets — database passwords, service-account keys — are encrypted before they are stored, under a deployment key held outside the database.
• A stored secret is never rendered back. Editing a connector shows its non-secret fields; the secret field is blank, and leaving it blank keeps the existing value.
• Secrets are scrubbed from logs and from error messages. A failed upstream call reports what went wrong without echoing what it was holding.
• End users never receive a credential at all. They call a tool; Atrium makes the upstream request.

Tenancy

Every record belongs to an organization, and every query is scoped by it. A connection acts under exactly one organization — a multi-org user picks which by connecting to that org’s endpoint path.

What the model is allowed to influence

Assume the assistant’s context can be poisoned, because it can. Atrium’s defense is that the security-relevant decisions are not in the model’s hands:

• The tool list is resolved from the caller’s roles before any model input is read. There is no tool argument that widens it.
• Curated named queries are authored by you, parameterized, and never rewritten at runtime. Scope values are bound server-side and are absent from the schema the model sees.
• Result size is capped, so a query cannot be steered into returning an unbounded payload.

How roles and scope work →

What Atrium does not do

• It does not edit your config files or shell out to install packages. For catalog servers it returns instructions and lets you act — an MCP server that installed software on command would be a prompt-injection target that no security review should pass.
• It does not proxy servers your client could reach on its own. Atrium is in the tool-call path only for the sources you explicitly host, and nowhere else.
• It does not expose draft connectors. A server is reachable over MCP only once it is published and granted.