Connections and keys

An agent reaches a system through a connection. Four kinds exist.

An API key or token that you paste once.

A sign in, where you authorise Scytian in your provider’s own window. Microsoft 365 works this way, so nobody has to register an application to get started.

A service account, for systems that work that way.

An MCP server, when a vendor offers one and the job needs it.

What happens to the value

It is encrypted the moment you save it and stored in your own container. It is never shown back, not to you, not to us, not to the agent. The agent calls a connection by name and the platform opens the door, so the value cannot end up in a prompt, a log or a chat.

If a key is ever pasted into a conversation by mistake, treat it as exposed and rotate it. The platform redacts what it recognises, but the right answer to a key in a chat is a new key.

Scope

The narrowest access that does the job. Read only where reading is enough. One mailbox rather than the domain. A bank connected to be read, with no payment rights anywhere on the platform to grant.

Each connection records who granted it and when, and each job carries only the connections and tools it needs.

Taking access away

Revoking a connection is one action on your side and it stops the jobs that use it. Nothing else breaks, and the timeline keeps the record of what was done while the access existed.