Connector patterns

Connectors differ less in the product behind them than in the way they sign in to the target system. That way of signing in is exactly what determines where the data boundary sits and how much work you have in the admin panel.

Three shapes cover practically everything that comes up in a small or medium business. This page describes each one with the same three questions: what it is good for, how the permissions flow, and what you have to watch out for. Which product you actually attach makes no difference to the shape.

Pattern A: business application through a service account

What it is good for. Your ERP, your inventory management, your accounting, meaning the systems with customers, documents, projects, and personnel data. Applications like these usually offer a technical access path through a key, but no per-person access through an interface.

How the permissions flow. The connector holds a technical access path and signs in the same way for everyone. The target system does not know the person making the request, it only sees the service account. It therefore cannot tell your staff apart.

The answer to that is not a filter in the prompt, it is the structure of the accounts: one service account and one connector instance per permission profile, rather than a single master key for everyone. An access key fully inherits the permissions of its account in the target system. That makes the account behind the key the actual data boundary, not the configuration and not the prompt. What the account is not allowed to see, the chat does not see either, no matter what the model tries.

The grants in Kisuno come on top of that. They decide who gets to see which instance at all. If a grant in the panel is ever set too widely, the permission boundary of the service account still holds.

Instance with its own service account	Intended for
widest permission profile	management
commercial view	finance and administration
technical view without commercial data	service and projects

Which permissions these profiles actually carry is defined in the target system, not with us.

What to watch out for.

Grant exactly one instance per person

If several instances of the same connector are running, they expose identical tool names. If two of them are granted to one person, the same tool catalog lands in every conversation twice. That costs double the context tokens on every message, and the model has to guess between two identically named tools, which leads to wrong calls.

So grant exactly one instance per person. If someone needs a different profile, switch the grant instead of adding a second one.

Three points on top of that matter in day to day work:

• Set the default rule to denied right away. Set the default rule of every instance to denied before you grant access to anyone.
• Keep the release in the target system read only wherever the use case allows. Enable writing, creating, and deleting only for the individual objects where you genuinely have the need.
• Use the log. Every decision is written down immutably. In the log of the target system you can additionally tell which profile a query came from. Separate service accounts pay off a second time here.

If you need a finer separation, the way to get it is not an extra filter in the chat, it is another account with narrower permissions and another instance of the connector.

Pattern B: file storage with per-person sign-in

What it is good for. Your document management, your cloud storage, your team file shares. So systems where the access permissions are already maintained finely and per person, and where a per-person access path through an interface exists.

How the permissions flow. Every person signs in once themselves. On first use they pick the tool in the chat and click connect, land in the familiar sign-in dialog of the target system, confirm the access there, and from then on the connector works with their personal access.

That means: someone who is not allowed to see a folder in the target system does not see it in the chat either. The permissions are maintained where they are maintained anyway, and do not have to be rebuilt with us. A permission change in the source system takes effect in the chat right away.

This is the preferred route. If a system offers this kind of sign-in, take it. The permissions of the target system are already the boundary, and they are finer than a rule in front of it could ever be: down to document and field level instead of only down to connector and tool level.

Here the control sits in the target system

Because the person’s permissions are already the boundary, the authoritative control for a connector like this sits in the target system. Maintain it there, and do not plan on rebuilding a finer gradation in front of it.

What to watch out for.

• The acceptance test is a comparison. Two test users with different permissions in the target system have to demonstrably see different amounts in the chat. If each of them sees everything, the connector is not working with the person’s permissions.
• Read only wherever that is enough. An explicit read only switch in the bridge is worth more than the intention not to write. Areas the use case does not need, such as mail, calendar, or chat history, are best not enabled at all. Every additional permission requires fresh consent anyway.
• The access has to survive and be renewable. If the permission to renew the connection in the background is missing, it dies after a short while and every person has to connect again.

After a migration the keys of the instance have to come along

The personal access paths are part of the protected data of your instance. If you move to a new server, the corresponding keys of the old instance have to be carried over. If that does not happen, all stored connections are unusable and every person has to set up their access again. No data is lost in the process, but it is one support case per member of staff. Put this point on your migration plan, see backup and migration.

Pattern C: read-only bridge to a specialist system

What it is good for. Your monitoring, your inventory, your ticketing system. So specialist systems you want information out of, but where nobody should change anything from the chat.

How the permissions flow. Technically this is a service account like in pattern A. The difference lies in the intent: here the point is to read and nothing else. And that is exactly where the effort of genuinely enforcing read-only rather than promising it pays off. Three levels contribute to that, and each one would be enough on its own:

• The technical access in the target system gets read permissions only. With that, the target system rejects every write call itself, independently of our software.
• The bridge offers no writing tools at all. What does not exist cannot be called.
• The grant decides who sees the tools in the first place.

The hardest boundary is a different one. These levels prevent writing. They say nothing about how much may be read. By default a technical access path usually sees the whole system.

So give the technical access in the target system only the areas it genuinely needs. What it does not see simply does not exist as far as the chat is concerned. That is the hardest boundary available, it sits entirely with you in the specialist system, and it can be bypassed neither by a prompt nor by a bug in our software. If you need several views, the way is the same as in pattern A: a second technical access path with a narrower area, a second instance of the bridge, and in the panel every person gets exactly one of them.

The rule behind it

A tool that does not exist cannot be called by a model by accident. So do not build tools for intervening actions, such as reboots or script execution, in the first place. Then no rule is needed anywhere that would have to prevent someone from restarting a server from the chat. It simply is not possible.

That is exactly the measure you apply to a third party connector: which tools does it expose, and is there a read only mode? If a ready-made server offers intervening actions alongside reading and that cannot be switched off, a narrow bridge of your own is often the faster solution than the discussion about who is allowed to use it.

What to watch out for.

• A self-test is worth the effort. A small check program that proves the sign-in, the permissions actually granted, and a read access turns an assurance into evidence. It can be run again after every change.
• Staged responses save on every question. A detail query should first load only the master data and deliver extensive sections only on explicit request.
• For questions about many objects, use an evaluation tool. Ten individual queries cost ten results in the context, one evaluation costs one.
• Everybody sees the same thing. The specialist system does not know the individual chat user, it only sees the technical access. The separation between your staff is made solely by the grant in the panel and by the area you gave that access.

What the tool catalog costs

All three patterns share one property: the tool catalog of a connector, meaning the name, description, and parameters of every tool, is sent to the model with every single message. It is not a one time investment, it is ongoing rent on every chat.

The order of magnitude is substantial: a large connector can offer more than a hundred tools and thereby occupy a considerable share of the available context before the first question is even asked. Narrowed down to the use case, often only a small fraction of that remains.

The second effect is at least as important: the more similar sounding tools there are in the catalog, the more often the model reaches for the wrong one. A narrow catalog delivers not only cheaper but also more reliable answers.

So enable tools one at a time and on request, not as a precaution.

Permissions and grantsWhat the permission check decides on and where you maintain the grants.

Connecting your own connectorWhat to settle beforehand, how to measure a third party connector, and what counts when granting access.

Best practices for connectorsTen rules with reasoning, plus a checklist to run before granting access.