Connect once, not once per agent

The first agent is the easy part. You give it access to the warehouse, it answers a question in plain language, and for a moment it looks solved. Then the questions start. What identity did the agent use to get in. If it was a shared service account, which it usually is, you can no longer tell which person's request it was acting on, or limit what that person was allowed to see. The agent worked. The control you had over your data did not survive the introduction.

That is the real problem with connecting agents to a data platform, and it arrives the moment you look past the demo.

Your data platform assumes a person is asking

A data platform is not open. It is protected by four things, and all four were designed around people.

Identity decides who you are, usually through single sign-on. Networking keeps the platform behind a private boundary, reachable only from inside. Credentials prove a right to connect. Governance decides, once you are in, which rows, columns and tables you may see, and records what you did.

A person fits this cleanly. They log in, their role sets their access, and the audit log carries their name. An agent fits none of it. It is not a person, so whose access does it get. It usually runs outside your network, in a vendor's cloud, so the private boundary is in its way. It needs a credential of its own, which now has to live somewhere. And whatever it reads still has to respect the governance that would have applied to the person behind the request.

Identity, networking, credentials and governance all assume a person is asking.

Each of those is a small problem for one agent. They stop being small when you have several.

The trap is wiring each agent directly

The obvious path is to connect each agent straight to the data, and it is the path that hurts later.

Every framework you adopt needs its own credentials, so copies of secrets spread across clouds and config, each one a thing to rotate and a thing to leak. To let an outside agent reach a private platform, someone opens the network a little, and closed boundaries drift open one exception at a time. To avoid per-user complexity, agents are handed a single shared service account with broad rights, and the moment that happens you lose the two things you most needed to keep: which real person the request belonged to, and the limit on what they should have seen.

You connected an agent and gave away the answer to who was asking.

That is the exposure. The management burden sits right behind it.

And then you have to keep it running

Setting a connection up is the small part. Keeping it running is the part that lasts.

Every integration wired separately is a separate thing to operate. Each one has to be monitored, renewed and kept in step with everything around it. Change your identity provider, rotate a key, tighten a network rule, and the change does not happen once. It happens in every place an agent was wired in by hand, and each place is a chance to miss one and break a workflow or leave a door open.

Audit is the same story in reverse. When security asks who accessed what, or an incident needs a timeline, the answer has to be reassembled from every agent's own logs, in every agent's own format, where those logs exist at all. Traceability that is scattered is not really traceability.

On day one nothing bites. It bites at the second framework, the first key rotation and the first security review.

And it grows. The second agent adds work. The tenth adds nine more integrations to watch, change and account for. What began as a task quietly becomes a role, and then a team, whose job is to keep the plumbing between agents and data from falling over. That is not the capability you set out to buy.

Solve the connection once, centrally

The alternative is to set the governed connection up one time, inside your own environment, and let every approved agent use it.

Datahub establishes that connection through the mechanisms the platform already respects: your identity provider, private networking, and a credential broker that holds the secret in one place so no agent ever receives it. Agents do not authenticate to the data platform. They ask through the governed connection. The connection checks whether the caller is allowed, applies your governance policy, and records who asked. What the agent gets back is only what the person or process behind it was permitted to see.

Identity is set at the door and never traded away for a shared account.

Because the connection is defined in one place, so is the work of keeping it running. You change an identity rule, a network route or a credential once, and every agent that uses the connection changes with it. The record of who accessed what lives in one place, in one format, ready for an audit rather than assembled after one. Adding the tenth agent is granting access, not building a tenth integration. And the hard questions stay answerable: who asked, whether they were allowed, and what they saw.

The same number of agents, a completely different maintenance profile.

A foundation should remove work, not relocate it

There is a version of adopting agents that looks like progress and is not.

Every agent brings its own portal, its own credentials and its own upkeep, and the organisation ends up with a new class of manual work to staff. People move off one maintenance job and onto another. The headcount that managed the old thing now manages the new thing. The tools changed and the business did not advance.

A foundation is meant to absorb the repeated work, not relocate it.

It is meant to do the opposite, so that adding capability does not add operating load, and so the people you have are consuming intelligence rather than maintaining the pipes that carry it. That is the difference between getting ready for the next stage and relabelling the current one. Scaling means the next agent is nearly free to onboard, not another line on someone's run book.

This is where Datahub is aimed. Not at connecting one agent to your data, but at making that connection something you set once and build on, so that more agents mean more capability instead of more to manage.

This is the wall right after the first agent

It is worth being honest about timing. Most organisations have not felt this yet. They are still getting a first agent to work, and on day one none of it bites.

It bites as the count grows. It bites at the second framework, the first key rotation across several agents, the security review that asks who a shared account represents, the audit that wants a name and finds a service account. The work of setting one governed connection up is real, and it is done once. Everything after it is access, not another build.

Connect once. Change in one place, audit in one place, and add agents without adding integrations. The alternative is not only a weaker security posture. It is a permanent job you created for yourself, and it grows with every agent you run.