← Library

Bring Your Own Tools, Safely

An agent that can only talk is a demo; an agent that can act is a coworker. The hard part was never deciding agents should use tools. It's the connection, the credentials, the auth, and the audit underneath. Here's how thinqOS handles all four.

An agent that can only talk is a demo. An agent that can act, reading your Sentry issues, posting to the right Slack channel, querying your internal API, is a coworker. The hard part was never deciding that agents should use tools. It's everything underneath: how a tool gets connected, who holds the credentials, how the auth handshake happens, and whether anyone can see what the agent actually did. Most systems answer those questions with hardcoded integrations and API keys pasted into a config file. thinqOS answers them with a standard protocol, self-managing authentication, encrypted secrets, and a complete audit trail.

This paper is about that machinery, because for a technical buyer the machinery is the value.

The usual way, and its costs

The common pattern for giving an agent tools is bespoke integration. Each new service is a code change. Credentials are handed around as plaintext keys. There's no standard surface, so every tool is shaped differently, and there's rarely a per-call record of what the agent did with the access you gave it. It works until you have more than a handful of integrations, more than one user, or a security review.

thinqOS is built on the Model Context Protocol (MCP), the open standard for connecting AI systems to tools and data. But adopting the protocol is only half of it. The interesting work is in being a well-behaved citizen of that protocol on both sides.

Server and client at once

thinqOS is simultaneously an MCP server and an MCP client.

As a server, it exposes its own agents and capabilities as MCP tools and resources, meaning an agent can itself be a building block that other systems, including other agents, call.

As a client, it connects outward to upstream MCP servers, Slack, Sentry, your own services, and forwards calls to them on an agent's behalf. This dual role is what makes the tool layer composable: external tools plug in through one standard door, and thinqOS's own capabilities go out through the same one.

The transport is stateless HTTP, which keeps the server horizontally scalable. One honest consequence of that choice, worth stating because it occasionally surprises people: because the connection is stateless, a client's view of the available tool catalog refreshes when it reconnects rather than being pushed live. Add a new tool and existing sessions keep their cached list until they reconnect. That's a deliberate trade for scalability and statelessness, not an oversight.

Self-bootstrapping authentication

This is the part a security reviewer should linger on, because it's where most "we support OAuth" claims get thin.

When thinqOS connects to an upstream service that uses OAuth, it doesn't require an operator to pre-register an application, copy a client ID, and paste in a secret. It performs the whole handshake itself, to spec:

• It discovers the service's auth configuration by walking the standard metadata endpoints, first the protected-resource metadata, then the authorization-server metadata, with fallbacks for the real-world cases where services structure those endpoints differently.
• It registers itself dynamically as a client using Dynamic Client Registration, obtaining its own client identity from the upstream server without manual setup.
• It uses PKCE (the S256 challenge method) on the authorization code exchange, so the flow is secure even as a public client.
• It refreshes tokens pre-emptively, before they expire, and it does so under a row-level lock, so that when many requests need a refresh at once across multiple server instances, exactly one refresh happens. That detail matters: some providers rotate refresh tokens and treat a reused one as a replay attack, so naive concurrent refreshing would burn the token and lock you out. thinqOS serializes it correctly.

The short version: you point thinqOS at a service, approve access once in the normal OAuth consent screen, and the platform handles registration, tokens, and refresh from there.

Secrets and the lifecycle, by design

Credentials are never stored as bare plaintext. Secrets are encrypted at rest. The schema permits only three reference forms: an encrypted inline value, an environment reference, or a managed cloud-secret reference. That constraint is enforced at the database level, not just by convention.

The integration model is layered so that a definition (what the service is) is separate from how you authenticate to it, which is separate from a specific installed instance, which is separate from a particular identity's credential on that instance. The practical result is that the same service can be connected by multiple people, each with their own credentials, each independently revocable, without anyone sharing a key. Isolation is the default, so one identity's compromised credential has a contained blast radius: it cannot reach another identity's installs.

Every call is on the record

When an agent invokes a forwarded tool, the call is logged, and logged in a place deliberately kept separate from the AI-model usage ledger, so that tool traffic and model traffic never contaminate each other's accounting. Each record captures which agent made the call, which tool, how long it took, and whether it succeeded, with sensitive arguments and secrets redacted out of the stored copy. Responses stream straight through to the caller rather than being buffered, so the audit layer adds a record without sitting in the data path.

The shape of it

Standards-based connectivity, authentication the platform manages for you end to end, secrets that are encrypted and individually revocable, and a redacted per-call audit trail kept clean of your model accounting. That's the difference between an agent that can use tools and an agent you'd actually let near production systems.

Part of the thinqOS science series, by AI4Outcomes.