Should organisations treat agent connectors and federation links as part of identity governance?

Why connector and federation paths belong in identity governance

Connector registrations and federation links are not just plumbing. They are access paths that can let an agent authenticate, inherit trust, and reach downstream systems on behalf of the business. Once a link can create, extend, or revoke effective access, it belongs in identity governance because it changes who or what can act, under which authority, and with what blast radius.

That is why teams should evaluate these paths the same way they evaluate entitlements, not as pure integration metadata. A connector that can read mail, post tickets, query data, or trigger workflows is functionally granting capability, even if the user experience presents it as a setup wizard or a federation handshake.

For governance purposes, the key question is whether the path changes reachable authority. If the answer is yes, the connector or federation link should be inventoried, reviewed, approved, monitored, and revoked through the same control plane that handles access changes. IAM and IGA Basics is a useful foundation for treating those capabilities as governed entitlements rather than informal integrations.

What changes when a connector becomes an entitlement

The practical shift is from “can the agent talk to a system?” to “what can the agent do in that system, and on whose behalf?” A connector may be narrow, but it can still expose privileged data, expand write access, or create impersonation paths through delegated tokens and federation assertions. That makes the connector part of the effective access model, not a sidecar to it.

Federation has the same issue. A trust relationship can remove local passwords while still granting broad downstream access, so the governance object is the trust edge itself: issuer, audience, scopes, claims, and revocation behavior. If those elements are unmanaged, the organisation may lose sight of who can exercise authority after the original registration step.

This is also where lifecycle discipline matters. Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics both support the same core principle: when access paths change, the access model must change with them. If a connector is still active after the business need ends, the entitlement has effectively outlived its owner.

How to govern connectors and federation links in practice

Start by putting every connector, federation trust, and tool registration into an inventory that includes business owner, technical owner, source of authority, target systems, scopes, and expiry or review date. Then require review of the reachable actions, not just the integration record. A connector with read-only intent but write-capable scopes is a governance defect, not a minor implementation detail.

Next, align review cadence to risk. High-impact links, especially those that can reach production systems, customer data, or admin functions, should be subject to explicit recertification and rapid removal when the business case changes. For access review mechanics, Access Reviews and Certification Guide is directly relevant because it treats effective access as something to verify and close out, not merely to record.

Finally, apply least privilege and separation of duties to the connector design itself. Segregation of Duties (SoD) Guide is useful when a single connector can both request and approve action, or when a federated path can bypass normal approval boundaries. The design goal is to make delegation explicit, bounded, and reversible.

Risk and Threat Considerations

Connector and federation risk is often underestimated because the control failure hides inside “trusted” integrations. If a token, trust relationship, or connector registration is over-scoped, compromised, or forgotten, an attacker can reuse that path to access multiple systems without needing to break each target individually. The result is a larger and flatter attack surface than the organisation intended.

Failure mechanism: Excessive scopes, weak review, and stale federation links let a non-human pathway keep authority after the original operational need has changed. In practice, that creates persistent access, privilege creep, and a simpler route to lateral movement or data exfiltration if the connector or upstream identity is abused.

Impact: One weakly governed link can become a high-value access path across multiple applications, especially where the connector can act across environments or impersonate users. That increases blast radius, complicates incident response, and makes revocation slower because teams must unwind the trust path, not just reset one credential.

Practitioner Guidance

What to verify: Verify that every connector and federation link has a named business owner, an explicit purpose, and a documented scope that matches the actual permissions in use. If the grant is broader than the business case, treat it as an excess entitlement rather than an integration exception.

Decision rule: If a connector can read, write, impersonate, or trigger actions in a downstream system, govern it like access control, not like configuration metadata. If it only forwards non-sensitive telemetry with no authority transfer, a lighter review may be sufficient.

Practitioner takeaway: The safest operating model is to assume that every trust edge is an entitlement until proven otherwise, because authority often enters the environment through integrations long before it is visible in ordinary access reviews.

Related resources from NHI Mgmt Group

• When should organisations treat agent intent as part of identity governance?
• What is the difference between human identity governance and AI agent governance?
• When should organisations treat an AI agent as a privileged system?
• When should organisations treat agent output integrations as part of access governance?