How should security teams govern AI agents and model access after an acquisition expands the security platform?

Why This Matters for Security Teams

An acquisition usually adds more than products. It adds new model endpoints, agent runtimes, service accounts, OAuth grants, data pipelines, and overlapping control owners. That is where AI risk becomes a governance problem, not a tooling problem. For autonomous systems, static access reviews are too slow and too coarse because the agent’s behaviour changes with prompts, context, and tool chaining. Current guidance from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both point toward runtime controls, least privilege, and explicit accountability.

NHIMG research shows the scale of the exposure: in the AI Agents: The New Attack Surface report, 80% of organisations said AI agents had already acted beyond intended scope, while only 44% had implemented policies to govern them. That gap matters after an acquisition because inherited agents often retain pre-merger permissions, undocumented integrations, and unclear ownership. In practice, many security teams discover excessive AI access only after an agent has already touched sensitive systems or shared data outside its intended workflow.

How It Works in Practice

Governance should start by inventorying every AI agent and model entry point, then mapping each one to a business owner, data domain, and execution boundary. That includes internal copilots, workflow automations, embedded assistants, and model APIs inherited through the acquired platform. The objective is to replace broad, static entitlements with context-aware controls that evaluate what the agent is trying to do at request time, not just what role it has on paper. For autonomous workloads, the strongest pattern is workload identity plus short-lived credentials, so the system proves what the agent is and only grants what it needs for the current task.

Security teams should align the merged environment to policy-as-code, using runtime enforcement to decide whether a tool call, data lookup, or external API action is allowed. That policy layer should include approval paths for high-risk actions, tight logging for every tool invocation, and automatic revocation when a task completes. This is where runtime governance connects to model scanning and posture management: scanning finds risky configurations, while runtime policy prevents those risks from becoming incidents.

• Assign a unique workload identity to each agent or agent class.
• Issue just-in-time credentials with short TTLs and automatic revocation.
• Review all tool permissions, OAuth grants, and API scopes inherited in the acquisition.
• Log prompts, tool calls, and data access with enough context for audit and incident response.

The control model should also account for lateral movement between tools, because agent chains can escalate faster than a human operator can review. NHIMG’s The State of Non-Human Identity Security report highlights why this is hard: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and inadequate monitoring remains a top cause of NHI incidents. These controls tend to break down in highly integrated environments where the acquired platform was built around shared service identities and undocumented third-party connectors.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations have to balance blast-radius reduction against delivery speed and integration friction. Best practice is still evolving for agentic systems, especially where multiple models, orchestration layers, and human approval steps are mixed in the same workflow. In some cases, a model may need read access to broad context but only narrow write permissions, which means access has to be split by action type rather than by application team.

The edge cases appear when the acquired company uses long-lived secrets, shared robot accounts, or unmanaged browser-based agents. Those patterns can work temporarily, but they weaken traceability and make revocation unreliable. Security teams should treat prompt injection, tool abuse, and OAuth token theft as part of the same governance surface, not separate issues. Incidents documented in Gemini AI Breach and CoPhish OAuth Token Theft via Copilot Studio show how quickly a trusted agent can become a privilege broker when controls are too static. Current guidance suggests treating these cases with exception handling, not as proof that the broader governance model should be relaxed.

For acquired platforms with regulated workloads, the target state should also map to CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10. That gives teams a practical way to distinguish between normal automation and unsafe autonomous behaviour before the merged platform reaches production.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern access when they test a new frontier model through a shared AI gateway?
• How should security teams limit the risk from AI agents that have access to production systems?