Connectors with enforceable boundaries

An agent that can only see its own scratch space isn't worth much. The value shows up when it can read your tickets, search your wiki, pull documents and draft replies. That's also where the risk shows up, because every connection is a path for data to leave, for the wrong thing to change, or for someone else's instructions to get in.

In Stop telling AI agents what not to do, I argued for taking capabilities away instead of writing rules about them. This is the same idea applied to the connections themselves. In the systems I design, the agent never holds credentials for any service. It asks a gateway, and the gateway holds the credentials, enforces policy and keeps the record. What follows is how that gateway decides what to allow.

Permissions from the vendor aren't enough

The first instinct is to make a narrowly scoped token and call it done. It rarely works. Vendor permissions follow the vendor's idea of a role, which rarely matches yours. On GitHub, an agent that can push code and open pull requests already holds enough permission to merge them. In Jira or Confluence, a bot account may see things a human in the same role wouldn't, or the other way around. "Only these projects" or "only this team's tickets" is usually not something a token can express at all.

So the scope has to be enforced in front of the service, by something that understands what you actually mean.

Deny on ambiguity

Search is the hardest case, because a query language is a small programming language, and an agent, or anyone who has influenced it, can be creative. A good gateway doesn't try to sanitize arbitrary queries. It reads each query and accepts it only if it can prove the query stays inside the allowed projects. The shape has to be simple, with the project restriction at the top and nothing that could widen it. Anything it can't prove gets refused, including queries that would probably have been fine.

A false refusal costs the agent one retry with a simpler query. A false acceptance costs a leak. So when in doubt, the gateway refuses.

The same thinking applies elsewhere. When the agent asks for a page, the gateway checks which space it came from before handing it over, so an out-of-scope page never reaches the agent. When the agent lists what's available, it only sees what it's allowed to touch, so it can't map the rest of the system. A new connector starts with an empty allowlist, so it's installed but does nothing until someone turns it on. The ticket an agent was asked to work on is recorded for context, but it never grants access by itself.

A few narrow verbs

Writes get even more care. Instead of exposing the vendor's whole API, the connector offers a handful of specific actions, like create a ticket, edit one, comment on one and link two together. Some actions are permanently off the table. Deleting things and moving them through a workflow aren't available at all. The line mostly follows what can be undone. A comment can be edited and a ticket can be closed again, so an agent can do those on its own. A delete, a sent message or a status change that starts someone else's work can't be taken back, so either the verb doesn't exist or a person approves it. Every write is checked against an allowlist of fields, so an agent can't smuggle changes in through obscure custom fields. Notifications default to off, so an agent's edits don't email half the company unless someone asks for that.

What scoping doesn't stop

Scoping limits where an agent can reach. It doesn't stop misuse of the actions that are allowed. Inside an allowed project, an agent can still file noisy tickets, edit a description into something misleading, or leave a comment nobody should act on. Those risks are bounded rather than eliminated. Destructive operations aren't available at all, notifications stay quiet unless asked for, writes are rate-limited, every action is logged, and anything that matters still passes a person before it counts.

Safe retries

Agents retry. Networks fail, services time out, and an agent that isn't sure whether its write went through will try again. That's how you get three identical tickets. The fix is an idempotency key, but the detail that matters is how it's chosen. The key has to identify the logical operation, like "file the follow-up for this specific finding," and the same key has to be reused on every retry of that operation. Deriving it from the request's meaning makes that easy. A random key works too, as long as it's generated once and reused. What doesn't work is a fresh key on each retry, because then every retry looks new.

Log the shape of each call

Every call through the gateway is logged, with who made it, which role, what project, which action and what happened. What's never logged is the content. Ticket text, page bodies and comments stay out of the audit trail, and only their size and structure are recorded. An audit log that copies every confidential document it touches becomes a liability of its own.

The gateway also records who did what in a way the agent can't fake. When several agents work on the same branch, it notes which role created each change at the moment the change passes through, rather than trusting what the agent says about itself.

Treat what comes back as data

Everything a connector returns, whether a wiki page, a ticket or an email, was written by someone, and increasingly by other bots. Some of it will contain instructions aimed at whatever agent reads it. Connectors should hand that material over as information to work with, and the rest of the system should treat it that way. A better prompt won't defend against that. What does is that even a convinced agent can only use the narrow, scoped, logged actions the connector offers.

Grow access in stages

For a team just starting out, the most useful habit is to grow access on purpose instead of all at once. Start with no outside access at all. Then let agents read public material, then your own systems read-only, and only then let them write, through connectors like these. Learn how agents behave at each level before granting the next one, and treat every new destination as a decision someone made, never something that happens because an agent asked.