Security
The facts below describe how ToolGlue actually works, not aspirations. Each one is enforced in code and covered by tests.
Secrets at rest
Every workspace gets its own random data encryption key, itself protected so it is never stored or handled in the clear. Connection credentials, external server environment values, and similar secrets are encrypted AES-256-GCM under the workspace key with a fresh nonce on every write. Decryption happens only at the moment of use, in one audited code path.
The runner never sees secrets
AI-generated code runs in a separate sandbox container with no access to platform storage, encryption keys, or credentials. When sandboxed code calls an API, it presents a single-use grant token (60 second lifetime, bound to that one run and that one connection, with a hard call budget) to a proxy that injects the credentials server-side. The sandbox can only ever reach the one connection it was granted.
Egress guarding
Every outbound call ToolGlue makes on your behalf goes through an SSRF guard: the target must resolve within the connection's own host, DNS answers are checked against private and internal ranges and pinned for the actual request, redirects are never followed automatically, connections are HTTPS, and responses are capped at 10 MB.
Redaction
Run logs record each HTTP exchange with authorization headers, cookies, and every known secret value scrubbed before storage, and bodies truncated at 64 KB. AI build transcripts pass through the same redactor, and a test asserts a decrypted credential can never appear in one.
Agent authentication
The OAuth flow is OAuth 2.1 with PKCE mandatory: access tokens live 15 minutes, refresh tokens rotate and are one-time-use, and a replayed refresh token revokes the whole grant chain. API keys are stored as SHA-256 hashes, verified in constant time, and revocable instantly. Consent is never skipped, and every grant is bound to one workspace.
Agent tool changes need your say-so
By default, agents may run your tools but not create, rebuild, or delete them. When an agent wants to build something, a workspace Owner or Admin opens a temporary tool window under Settings, Agent tool changes for 15 minutes, an hour, or eight hours, and the window closes by itself, so permission is never left on by accident. Power users can set the policy to Open (agents may always change tools; everything is still audited) or Locked (never). Every tool also carries a declared read-only or destructive marker that agent clients can use to ask a human before destructive calls.
The scrutinizer screens meaning, not just mechanics
The sandbox limits what generated code can do; the scrutinizer screens what a request says. It asks a judgment model a fixed set of yes or no questions about AI build requests and connector drafts before any charge, about the generated result before it lands, and about Smart Tool inputs before inference, catching prompts that try to hijack a tool, harvest credentials, or smuggle instructions past the sandbox. The judgment model writes no text, so there is no verdict for a hostile prompt to rewrite, and every question must pass. An answer that is not clear either way is asked again in a second, differently shaped call before anything is decided. Owners and admins can add their own yes or no checks in Settings; those can only tighten the policy, never switch a built-in check off. The hardening level is tunable per workspace from Minimal up to Max, where an unsure or unavailable scrutinizer denies instead of allowing. Blocked requests are never charged and always audited.
Tenancy and audit
Workspace isolation is structural: every workspace-owned record is filtered and write-guarded at the data layer, with row-level access controls underneath as defense in depth. An append-only audit trail records logins, key events, grants, money movements, and every significant mutation; workspace Owners and Admins can read it on the Audit page.