Topic starter
25/08/2026 9:13 am
TL;DR: AI agents, MCP servers, and delegated tool access are creating a runtime identity problem that traditional automation controls were built to assume away, according to Britive. The core shift is that access must be verified, constrained, observed, and revoked continuously because agent behaviour can change mid-task and invalidate standing-access assumptions.
Editorial analysis by NHI Mgmt Group, based on content published by Britive: “Securing AI Agents Beyond the MCP Gateway”.
By the numbers:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
Key questions
Q: What breaks when AI agents bypass a centralized MCP gateway?
A: When agents bypass a centralized MCP gateway, security controls fragment across notebooks, scripts, and individual servers.
Q: Why do AI agents create a different access-risk profile than traditional applications?
A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path.
Q: How can teams tell whether agentic access controls are actually working?
A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution.
Practitioner guidance
- Map agent identities to named owners Require every AI agent to have a named human owner, a documented business purpose, and a visible inventory record so ownerless identities can be flagged and removed.
- Replace standing privilege with task-scoped access Issue privilege only when an agent is authorised for a specific task and remove it immediately when the task ends or the context changes.
- Centralise MCP connections behind a single control point Restrict backend MCP servers so only the gateway can reach them, and keep tool visibility limited to what each agent identity is explicitly entitled to use.
Bottom line: AI agents turn access into a runtime governance problem because their behaviour can change after authorization has already been granted.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/08/2026 9:14 am
Runtime authorization is now the governing unit for AI agents. Static access decisions assume the identity, intent, and scope of a session stay stable long enough to be provisioned once and reviewed later. That assumption fails when an agent can choose methods at runtime and change behavior mid-task. The implication is that identity governance must move from account-centric control to action-centric control.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should teams do when an AI agent's behaviour changes mid-task?
A: They should treat that as a live authorization change, not a later review item. If the agent's request pattern, data use, or command set diverges from the approved purpose, access should be re-evaluated and revoked before the session continues. The goal is to stop the task from outrunning the approval it was granted.
👉 Read our full editorial: Securing AI agent identity beyond the MCP gateway