How should organisations govern internally built AI agents versus purchased ones?

How internal build and procurement change the governance model

Internally built agents deserve lifecycle governance because the organisation can define the identity model, ownership, approval path, and retirement process. That makes registration, inventory, and policy enforcement realistic. Purchased agents are governed differently: the enterprise often controls use, not construction, so governance needs to focus on contract terms, vendor assurances, and whether the product exposes enough administrative hooks to enforce internal policy.

That difference matters because governance is not just about approving an agent once. It is about who can change it, who can revoke it, how changes are recorded, and whether the organisation can still answer basic questions about what the agent is allowed to do after deployment. For internal builds, those questions are usually answered by design. For purchased tools, they must often be verified through product capabilities and vendor commitments.

Purchased agents can still be governable, but usually through a narrower control surface. Teams may be able to set scopes, restrict connectors, review logs, or disable features, while leaving the underlying agent architecture opaque. Internal teams should treat that as a different operating model, not a weaker version of the same one. The control objective changes from full lifecycle management to bounded trust, documented permissions, and a reliable path to disable or replace the service if the vendor changes behavior.

Where ownership, revocation, and permission scope diverge

Ownership is the practical dividing line. With internally built agents, the business can assign a named owner, define a steward, and make offboarding part of the normal release and decommission process. With purchased agents, ownership is often shared across security, procurement, legal, and the business sponsor, so the governance question becomes who can actually act when the tool needs to be suspended, reconfigured, or removed.

Revocation also differs. An internal agent can often be retired by disabling its credentials, removing its backing service, or changing its policy bindings. A purchased agent may require vendor-side action, subscription changes, or administrative workflow the organisation does not fully control. Good governance therefore tests revocation before go-live, not after an incident, because the ability to stop an agent quickly is part of the control itself.

Permission scope should be managed as if the agent were a third party with operational reach. Internal builds can be reduced to task-scoped, time-bounded access under the enterprise's own policy. Purchased agents should be reviewed for vendor-visible permissions, data exposure, connector scope, and whether the product supports least privilege rather than broad default access. If the product cannot express the needed constraints, the governance decision is to narrow the use case, not to assume compensating controls will fill the gap.

What good governance looks like in practice

For internal agents, good governance looks like an inventory entry with an owner, purpose, approval path, and retirement criteria. For purchased agents, it looks like a documented supplier control model that records what the vendor can see, what the enterprise can revoke, which permissions are delegated, and what evidence is available for periodic review. In both cases, the goal is the same: no agent should operate outside a named control boundary.

One useful test is whether the organisation can answer four questions without guesswork: who owns the agent, who can change its access, who can shut it off, and what evidence proves those actions happened. If the answer differs sharply between internal and purchased agents, that is not a documentation issue, it is a governance gap. The more autonomy an agent has, the more important that gap becomes.

For purchased tools, the governance posture should be explicit about what is accepted as vendor-managed and what remains enterprise-managed. That usually includes approval thresholds, monitoring expectations, incident notification timing, and exit criteria if the vendor cannot meet internal policy. Internal build and buy decisions should therefore be treated as control-design choices, not just sourcing choices.

Risk and Threat Considerations

The main risk is assuming both classes of agent can be governed the same way. Internal agents can accumulate excessive access over time if lifecycle ownership is weak, while purchased agents can create blind spots if teams rely on vendor assurances without being able to revoke access or verify scope.

Failure mechanism: Internal agents fail through over-permissioning, poor offboarding, or stale ownership; purchased agents fail when opaque permissions, weak revocation paths, or vendor-side changes make the enterprise unable to enforce its own policy.

Impact: The result can be unauthorized action, data exposure, persistent access after business need has ended, or an inability to contain the agent quickly when behavior changes.

Practitioner Guidance

Decision rule: If you can directly register, name, and retire the agent, govern it like an internal identity-bearing system with full lifecycle control. If you cannot, govern it like a constrained external service and require evidence of revocation, scope limits, and vendor-managed change control before approval.

What to verify: Confirm that the agent has an owner, a defined purpose, a current permission set, and a tested shutdown path. For purchased agents, verify whether those controls exist in the product or only in the contract, because contractual rights are weaker than technical revocation when response time matters.

Practitioner takeaway: The build-versus-buy distinction is really a question of control depth, not trust level, and governance should become stricter as the organisation loses direct control over identity, permissions, and revocation.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• How should security teams govern API keys used for generative AI access?
• How can organisations govern AI agents that use service accounts and tokens?
• How can organisations govern AI agents without slowing operations?