Connecting software

Six kinds of connection. Four attach software you already run — an MCP server, an OpenAPI service, a REST API, or a database. Two are the platform itself: the built-in toolkit, and agent delegation, which turns your own agents into tools for each other.

Each has an article of its own. What follows is true of all of them.

What happens to your credentials

They are encrypted before they are stored, with a key that is itself encrypted. They are decrypted only at the moment a call is made, inside the connector.

They never appear in a prompt, a log, an audit record or an execution trace. The model is never told them and could not use them if it were — it names tools, and the platform makes the calls.

Nobody, including a platform administrator, can read them back.

What we refuse to connect to

URLs are checked on save and again on every single request, including redirects. Private addresses, loopback, and cloud metadata endpoints are refused. A host that resolves publicly today can resolve somewhere private tomorrow, which is why it is re-checked every time rather than once.

Database connections

Queries are validated structurally: one statement, an allow-listed leading keyword, no schema changes anywhere, and no UPDATE or DELETE without a WHERE. Row and time limits apply on every call.

Your schema's own conventions are respected

The application that owns a database stamps created_at and updated_at on every write, and in many schemas a delete marks a row rather than removing it. An agent writing through a connection goes straight to the table and bypasses that application entirely, so the connector maintains those columns itself.

• •A row an agent creates gets created_at and updated_at set, where the table has them. A value you supply is left alone, so importing records with real historical dates works.
• •A row an agent updates gets updated_at moved forward.
• •A delete on a table with deleted_at, is_deleted, is_delete or deleted marks the row instead of removing it — so it can be restored, and so an application that assumed nothing is ever really deleted keeps working. Where a table has no such column, a delete is a delete, and the agent is told which kind it is about to do before it does it.

One thing to know: reading is unchanged. A row an agent has soft-deleted is still returned by the list and count tools, because filtering them out would also hide rows from reports that are supposed to count them. If you would rather soft-deleted rows disappeared from reads too, say so — it is a deliberate choice rather than an oversight.