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. A cheap screening model reviews AI build requests and connector drafts before any charge, reviews the generated result before it lands, and screens Smart Tool inputs before inference, catching prompts that try to hijack a tool, harvest credentials, or smuggle instructions past the sandbox. The hardening level is tunable per workspace from Minimal up to Max, where an unsure or unavailable scrutinizer denies instead of allowing. Platform admins can also supply their own scrutinizer policy text; the strict allow/deny verdict format is enforced by the platform and cannot be overridden. 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.