Connectors give an AI agent governed access to the systems your organisation already runs on: mail, calendars, documents, code, tickets, CRM and accounting. They are what turns an agent from something that can only talk about your work into something that can do it.
The design principle is simple. Nobody shares a credential with an agent. An admin decides which data sources exist and how broadly they may be owned. Governance decides which roles get them. The secret itself lives in an external vault, never reaches the agent, and every use is recorded. That is what makes agent access to third-party data an enterprise-grade decision your organisation can audit and revoke, rather than an API key pasted into a prompt.
Nestr ships ready-made connectors for the tools most organisations already use. Adding one is a matter of picking a tile: the endpoint, the transport, the authentication method and the OAuth client all come with it, so there is nothing to research or paste in.
A few connectors need an OAuth client that your deployment supplies. Those appear once an admin has configured one, so the tiles you see are the connectors your workspace can add right now.
The catalogue is a convenience, not a boundary. You can register a custom connector against any HTTP API or any Model Context Protocol server your organisation runs, including internal systems that will never appear in anyone's catalogue.
A custom connector carries the same governance as a ready-made one: the same ownership model, exposure controls, vaulted credentials and usage record. Registering one is an admin action, and it is where you point Nestr at your own ERP, data warehouse or in-house service.
Connector access is a double gate, and the two halves answer different questions.
This is deliberately not one permissions screen. Deciding the organisation may reach Xero at all is a different decision from deciding which role reaches it, and different people should make them.
Exposure is re-checked every time a credential is handed out, not only when access is granted. An admin who switches a connector off for role domains stops it flowing through bindings that already exist, rather than merely blocking new ones.
Granting access does not connect anything. The person whose account it is still has to sign in, and that consent is theirs to give.
Only the resulting tokens are kept, in an external secrets vault. They are never stored in the Nestr database and never travel to the agent. When an agent needs a connector, it receives a single-use handle rather than a secret, redeems it at the moment of use, and the exchange is written to a usage ledger.
You do not have to do any of this from the settings screens. Ask the assistant in plain language and it will walk the setup with you:
Can you set up a Gmail connector for our Sales role?
It will find the right template rather than guessing at an endpoint, ask who should have access, register the connector, bind it, and hand you back the connect link to sign in with. If a connector already exists it will say so instead of creating a second one.
The assistant works within your permissions here as everywhere else. If you are not a workspace admin it can prepare the request and tell you who can approve it, but it cannot grant access you do not have. See Nestradamus.
A connector can require a person to approve before an agent acts. The policy is set per connector: approve nothing, approve writes, or approve everything. You can also name specific operations that always need a person.
When an agent hits a gated action it pauses and asks in the conversation, naming what it wants to do. Somebody with the authority to answer approves or declines, and the run resumes from there. The agent does not proceed on silence.
This is human-in-the-loop control in practical form: not a blanket switch, but a per-connector dial you turn up where a mistake is expensive and leave off where it is not.
Every credential handout is written to a usage ledger: which agent, which connector, on whose authority, and when. Combined with governance lookback, that gives you two complementary histories: what changed in your organisation, and what your agents reached outside it.
This matters beyond good practice. If you are working towards EU AI Act obligations, traceability and human oversight are not features you add at the end, and role-scoped access with a per-use record is most of what an audit asks for.
Access can be withdrawn at three levels, and each takes effect immediately:
Because a role-domain connector belongs to the role rather than to a person, someone leaving a role loses that access as a consequence of governance, with nothing to remember to revoke.
.png){kind=logo}
