Use a brokered access model that enforces the same identity controls across both environments, rather than granting separate exceptions for each platform. The key is to preserve consistent authentication, least privilege, and revocation so the agent cannot become a hidden bridge between incompatible systems.
How a brokered access model keeps one agent from becoming two separate exceptions
The practical goal is not to give the agent two unrelated access paths, one for the modern platform and one for the legacy stack. It is to place both behind a common control point so authentication, authorisation, session handling, and revocation behave the same way regardless of which system the agent touches. That prevents the integration from turning into an unmanaged bridge.
A broker also helps when the legacy environment cannot support the same native controls as the modern one. Instead of weakening the stronger system to match the weaker, teams can preserve a single policy layer and let the broker translate only what is necessary. AI Agent Authorisation Guide is useful here because the core pattern is delegated, task-scoped access rather than standing, user-like access.
For healthcare specifically, the broker should be the place where the request is evaluated, the action is bounded, and the identity trail is preserved. If the agent can act in both environments but the logs, approvals, and revocation path differ by platform, you have created a hidden trust gap even if each platform is “secure” on its own.
What consistency should teams insist on across modern and legacy healthcare systems?
Consistent controls mean the same identity assurance, the same least-privilege rule, and the same revocation mechanism apply to both systems, even if the technical implementation differs. The agent should not gain broader access simply because the target is older or harder to integrate. Zero Trust for AI Agents is a good mental model for this because it treats each request as something to verify, not something to inherit from prior trust.
In practice, that means teams should define one access policy for the agent’s role, then map it to the minimum acceptable controls each platform can enforce. If the legacy system cannot support the same fine-grained model, the broker should compensate with stricter scoping, shorter-lived access, or additional approval gates rather than permanent exceptions.
Modern and legacy healthcare systems also tend to differ in audit quality. A good design keeps the evidence chain intact so you can answer who acted, what was accessed, when access was granted, and how it was withdrawn. AI Agent Observability, Audit and Incident Response Guide aligns well with that requirement because it emphasises action attribution and revocation readiness.
Why healthcare integration fails when teams let platform differences drive access policy
The failure mode is usually policy drift. Teams start with a clean brokered model, then add one-off grants for a legacy EHR, a pharmacy interface, an imaging archive, or a modern SaaS workflow. Over time, the agent accumulates broad reach through platform-specific exceptions, and revocation becomes incomplete because no one can prove every entitlement the agent inherited or reused.
This is especially risky when the agent can move between systems that were never designed to trust the same principal. A compromise in the agent, its token, or its broker can then expose both environments at once. Agent Identity Standards Tracker is relevant because cross-system identity chaining is exactly where teams need clarity on how trust is represented and propagated.
Legacy healthcare platforms also tempt teams to use service accounts, shared credentials, or broad integration tokens because they are easier to wire up quickly. That shortcut reduces friction in the short term but raises blast radius, complicates change control, and makes incident response slower when the agent behaves unexpectedly or a token is reused outside its intended workflow.
Risk and Threat Considerations
When an AI agent spans both modern and legacy healthcare systems, the main risk is that the broker or integration layer becomes a hidden corridor for over-privilege, token reuse, and lateral movement. The danger is not only external compromise, but also the gradual creation of access paths that no single system owner fully sees or can revoke cleanly.
Failure mechanism: Teams allow platform-specific exceptions, long-lived tokens, or shared integration credentials, then lose the ability to enforce one consistent identity and privilege model across both systems.
Impact: A single agent compromise can affect multiple healthcare systems, expand access beyond intent, weaken auditability, and make containment slower because revocation must be coordinated across incompatible platforms.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent access across two systems hinges on privilege boundaries and delegated authority. |
| Recommendation — Enforce per-action authorization and bound the agent to the minimum necessary privileges. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | An AI agent acting across modern and legacy systems can accumulate excess access. |
| Recommendation — Remove standing privileges and scope the agent to the smallest workable entitlement set. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Brokered system-to-system access depends on authenticating non-human actors consistently. |
| AC-6 — Least Privilege | The question explicitly calls for preserving least privilege across both platforms. | |
| AU-2 — Event Logging | Cross-platform agent access needs traceable actions and revocation evidence. | |
| Recommendation — Authenticate the agent and its brokered calls with a controlled machine identity. Limit the agent to the minimum access needed for each approved healthcare action. Log brokered access decisions and agent actions so revocation and review are provable. | ||
Practitioner Guidance
What to verify: Confirm that every path the agent uses is brokered, time-bound, and mapped to one accountable principal. If you cannot explain how access is revoked in both systems on the same day, the design is not ready for production.
Decision rule: If the legacy platform cannot enforce the same controls natively, tighten the broker rather than relaxing the modern environment. Use the strongest common policy that both systems can support, and treat any exception as temporary and reviewable.
Common mistake: Treating interoperability as permission to create a second identity model. The safest pattern is one authority model, one revocation path, and one audit story, even when the technical plumbing differs.
Practitioner takeaway: The integration is only safe when the broker preserves a single control plane for identity and privilege, because separate exceptions are how an otherwise narrow healthcare workflow turns into broad, hard-to-revoke access.
Related resources from NHI Mgmt Group
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
- When does AI agent access create more risk than it reduces?
- What is the difference between governing human access and governing AI agent access?