How a US Medical Research Organisation Connected Nine Systems to Its AI Agents in Under Two Weeks

Summary

A US medical research organisation of 200 staff wanted AI agents to act across all of its business systems, including IT, finance and HR, not just answer questions about them. The blocker was never capability. It was permission. An agent that reaches into identity, device management and finance has to carry no more access than the person using it, and the organisation had no way to prove that.

They signed with StackOne and started the same day. On the kickoff call the first connector profile was configured, the first account was linked, and the first live agent query ran against a real system. Nine business systems were connected inside two weeks. Thirteen days after signature, the team demonstrated a cross-system dashboard they had built themselves on top of those connectors.

The organisation

Two hundred staff. Research on one side, the ordinary machinery of a mid-sized organisation on the other: identity and devices, requests and approvals, procurement, expenses, finance, and the people systems behind all of it. Two people hold global administrator rights. Everyone else needs answers out of systems they will never be given a login for.

Protected health information is deliberately kept out of the systems StackOne connects to. It sits in clinical systems that are not connected here, and those systems are outside the scope of the AI programme entirely. That was their decision, made before StackOne was in the picture, and it set the scope of everything below.

Why they were cautious about agent access

The IT leader started from a hard requirement: whatever an agent can reach has to be bounded by the permissions of the person asking. Not the permissions of whoever set the integration up.

That requirement is where most agent tooling fails. A connector is linked once, with one credential, and every agent query afterwards runs with that credential’s rights. In an organisation where two people are global admins, that means every question anyone asks runs as an admin.

The finance leader pushed the same point from the other direction during onboarding. It was not enough that agents were scoped. The vendor’s own administrators must not be able to grant themselves access to systems they were never given. That objection did not get waved away. It became a workstream.

What won it: access control per connector and per account

StackOne grants access per connector and per linked account rather than per platform. A person who links their own account to a system owns that link. Another administrator cannot see it, act through it, or attach an agent to it. Explicit account management makes the boundary a setting rather than a convention, and the calls an agent makes are logged.

That is what changed the calculation. The list of systems worth connecting stopped being the short one they could afford to expose. It became the whole estate.

The granular access at the account level for a connector is a huge help. So now I feel confident that we can create connectors to everything.

IT leader, US medical research organisation

Two more controls carried weight here. Connectors can be customised to drop fields before they ever reach the agent, so a system can be exposed without exposing everything in it. In healthcare that is routine work: on other customers’ deployments StackOne has stripped social security numbers out of employee lists and removed a whole set of benefits actions from an HR connector. And logging captures the tool calls an agent makes, not the prompts and responses around them, with a 30-day default retention window. Useful for an investigation, empty of anything the organisation would rather not retain.

First value on day one

The kickoff call ran on the day the contract was signed. By the end of it the first connector profile was configured, the first account was linked and live, the first agent query had returned real data from a real system, and the agent was wired into the assistant the team already used.

The first questions they asked were the ones that had been expensive. Correlating identity policies and access logs to work out why a user had lost access used to mean opening several consoles and reading them side by side. It would have taken hours or days to figure out. Now it is immediate.

From one system to nine

The pace held after the first day. Identity and device management went first, then requests, procurement and expenses, then finance. Nine business systems were connected inside two weeks, eight of them within the first eight days.

Most of what they wanted already existed in a catalog of 510+ connectors. Two did not. StackOne built both during onboarding: Procurify, their procurement system, and Microsoft Intune, the other half of their device management. The Okta connector gained extra actions they asked for, and Jamf gained a managed authentication type. A further system, a contract tool with tenant-specific APIs, they took on themselves, because every connector is a configuration file a customer can fork and extend.

Thirteen days after signature, on a working call, the IT leader shared a screen and demonstrated something StackOne had not asked for: a dashboard spanning identity, device management, requests and the rest of the estate, assembled on top of the connectors they had linked. Everything on it was live and pulled from the source systems. They estimated it had taken about ten hours to build, and said most of that was the interface.

What changed during onboarding

The elevated-access objection raised in week one turned into shipped product inside the first month:

• Administrators can no longer see or act on another user’s linked accounts in the connection flow, and the same boundary was closed in the interactive playground shortly after.
• Explicit account management was enabled for the organisation, so account ownership is enforced rather than assumed.
• SCIM and just-in-time provisioning, with platform groups, so access follows the identity provider instead of a manual list.
• StackOne does not impersonate a customer organisation without explicit, time-boxed permission from that customer, for a named support reason.

On the compliance side the organisation inherited StackOne’s existing posture: SOC 2 Type II, GDPR and HIPAA compliance, with a Business Associate Agreement available on Enterprise plans. No Business Associate Agreement was required for this deployment, because no protected health information is in scope.

Where this goes next

The deployment today covers the teams closest to the estate. A broader rollout across the organisation is the next step, and the team is waiting on group-based provisioning before opening it up, which is the right sequencing rather than a delay. With access control per connector and per account in place, the IT leader is planning to extend agent access into more departments, starting with HR, and into more systems as they go.

The results

• First value on the day of signature. Connector configured, account linked, live agent query answered, all on the kickoff call.
• Nine systems connected inside two weeks. Eight of them within the first eight days.
• Access the organisation can defend. Per-connector, per-account grants, enforced account ownership, and a log of the calls agents make.
• A dashboard the customer built themselves. Live across their estate, thirteen days in, with no help from StackOne beyond the connectors underneath it.