Skip to main content
Giving an agent real access to your tools is a big step. This page explains the security model behind every connection.

The transparent proxy

All of an agent’s outbound traffic flows through a proxy between the sandbox and the internet. Credentials are applied there. When the agent makes a request to a connected service, the proxy attaches the right token on the wire. The agent’s own code and prompts never contain it.
The result: the agent has the capability to act in a service without ever holding the credential.

Why it’s designed this way

Large language models shouldn’t be trusted with raw secrets. A token in a prompt could surface in a log, a message, or a memory file. Skydive keeps credentials out of the agent entirely and injects them at the network layer. That removes the whole class of risk.

Secrets never leak

Tokens aren’t in prompts, logs, or memory. They live outside the agent’s reach.

Scoped per service

Each connection is limited to the service and permissions you granted.

You control the grant

Authorize narrowly or broadly, and revoke at any time.

Isolated sandboxes

Each agent runs in its own machine. One agent’s access doesn’t bleed into another’s.

Scoping access

You decide how much an agent can reach:
  • Per service: connect only the tools a given agent needs.
  • Per resource: for services like GitHub, grant specific repositories rather than everything.
  • Per permission: connections request only the scopes required for the work.

Revoking access

Remove a connection or rotate a key at any time. The agent loses that access on its next request. No lingering tokens, no manual cleanup.

A note on memory

Memory lives in the agent’s git repository, scoped to your workspace. It’s shared knowledge for everyone with access to the agent. Treat it like a team wiki, not a vault. Keep genuine secrets in secrets, not in things you tell the agent to remember.

Connect a service securely

See the authorization flow in practice.