AI Agents Are Connecting to Everything — and Nobody’s Governing Them: Why Agent Governance Became the Hottest (and Messiest) New Control Plane – Dorland

Somewhere in your infrastructure, an AI agent is running that nobody formally authorized. That line from Giant Swarm’s Dominik Schmidle is funny in the way smoke alarms are funny: it’s a clever sentence that also implies you may soon be explaining yourself to your CISO, your auditor, and that one engineer who still prints Jira tickets “for traceability.”

In a March 5, 2026 post titled AI agents are connecting to everything — and nobody’s governing them, Schmidle argues that agent adoption is outpacing control and proposes an “AI orchestration” layer—a governed control plane built on the Model Context Protocol (MCP)—to connect agents to tools without turning your stack into a haunted mansion of credentials, implicit permissions, and mystery integrations. The original article is worth reading for the core thesis and the framing; this piece is the expanded field guide for what comes next when you try to make it real in production. citeturn1view0

What follows is my attempt to answer the question platform and security teams keep asking in 2026: How do we let agents work across the organization without accidentally creating the world’s most enthusiastic insider threat?

From “chatbot” to “junior SRE with API keys”

The last few years trained us to think of LLMs as interfaces: you ask, they answer, you copy-paste. Agentic AI changes the energy in the room. An agent is not just describing what to do—it’s doing it by calling tools: reading logs, opening tickets, creating pull requests, querying databases, changing configs, or triggering pipelines.

Microsoft’s security team put it bluntly in 2025: autonomous agents aren’t a small extension of identity governance; they’re a new workload that should be handled with guardrails similar to how you’d manage a junior employee (clear boundaries, monitoring, and least privilege). That analogy resonates because it captures the two uncomfortable truths at once: agents can be useful, and they can also be wrong at machine speed. citeturn0search4

Now combine that with how most organizations actually ship internal tooling:

A helpful engineer wires an agent to Grafana, Slack, GitHub, and “just enough” cloud APIs.
They store credentials somewhere “temporary,” which is to say “permanent.”
They add more tools because the first demo worked.
Six weeks later, nobody can answer: Who approved this access, and where’s the audit trail?

That’s not a moral failing. It’s a structural problem: our governance models were built for people and services with predictable boundaries. Agents are neither.

Why “connecting to everything” is happening now

There are three forces pushing agent connectivity into overdrive:

1) The standardization effect: MCP as the “USB‑C for tools”

MCP, introduced by Anthropic in late 2024, has become a common way for assistants and agents to discover and call external tools through a consistent interface. Security journalists and researchers increasingly describe it as the protocol that makes tool ecosystems composable—sometimes dangerously so. citeturn2search4turn2search18

The key point isn’t that MCP is magic; it’s that it makes the plumbing repeatable. Repeatable plumbing leads to explosive adoption. Explosive adoption leads to “wait, who deployed this?”

2) Tool ecosystems are huge, and many are community-built

Once you have a standard, you get an ecosystem. Community MCP servers now exist for everything from code hosting to internal apps. That’s great for innovation, and also how you end up with a production-adjacent agent whose toolchain includes “a repo I found on the internet.”

Researchers have warned that MCP’s openness and composability introduce an implicit trust assumption in third-party tool providers—an assumption attackers love, because it scales. citeturn0academia26

3) Organizations want outcomes, not prompts

The pitch has shifted from “ask the model” to “ship the workflow.” If your agent can resolve an incident, triage alerts, or draft a patch, executives hear “automation.” Engineers hear “finally.” Security hears “new attack surface.”

All three are right.

The governance gap: why agents are uniquely hard to control

We know how to govern applications (SDLC, AppSec, IAM). We know how to govern humans (policies, training, access reviews). Agents break the model because they sit in between: they are software that behaves like an employee and changes behavior based on language context.

Here are the governance fractures that show up first.

Identity fragmentation: “Who is the agent, really?”

In many deployments, agents connect to multiple systems using separate credential mechanisms: API keys here, personal tokens there, “temporary” service accounts somewhere else. That fragmentation means your controls are inconsistent: the agent has access, but your centralized security tooling may not have visibility into how it is using that access.

Several industry write-ups point to this identity fragmentation as a major MCP-era loophole: even if a protocol enables context-aware access, it doesn’t automatically solve identity assurance or stop an impersonated identity from receiving sensitive data. citeturn0news17

Authorization drift: agents accumulate privileges like browser tabs

Humans are lazy in predictable ways; we keep permissions we no longer need because removing them is work and the blast radius is uncertain. Agents are lazy in more creative ways: they’ll keep asking for new tools and broader scopes because it increases their chance of completing the task. If the system makes that easy, you get “excessive agency” at scale—one of the risks that OWASP’s GenAI guidance flags across LLM and agentic systems. citeturn0search3

Auditability: “Show me the chain of custody for that action”

Auditors don’t care that the agent had good intentions. They care about traceability: what identity initiated the action, what data was accessed, what tool was called, what was changed, and what approval existed at that moment in time.

Giant Swarm’s blog post calls out the lack of a clear audit trail as a production blocker and proposes tying actions to user identity via SSO, blocking destructive operations by default, and logging everything via an orchestration layer. citeturn1view0

Composability risk: safe tools can become unsafe in combination

Agent systems fail in unexpected ways when multiple components interact. This is not hypothetical. Security reporting in early 2026 described vulnerabilities in Anthropic’s Git MCP server that researchers said could be chained with other MCP tools (like filesystem access) to produce remote code execution or file tampering scenarios. citeturn2news12turn2search4

This “toxic combination” effect is the agent era’s answer to microservice misconfiguration cascades—except now the orchestrator is a language model that can be socially engineered through content.

MCP in 2026: the protocol helps, but it doesn’t govern you

MCP is frequently described as the standard that connects models to tools. That’s accurate, but incomplete. A protocol can standardize how you connect. It cannot, by itself, solve whether you should, under what policy, and with what monitoring and accountability.

To its credit, MCP has been moving toward stronger authorization patterns. Documentation around MCP authorization describes OAuth 2.1 as a foundation and points to capabilities like dynamic client registration. citeturn2search2turn2search9

But two things remain true at the same time:

OAuth is necessary to avoid a world of hardcoded API keys and orphaned agent access.
OAuth is not sufficient if you treat the MCP server like a toy sidecar rather than a first-class service with policy enforcement, telemetry, and lifecycle management.

That distinction matters because many of the nastiest real-world failures happen “inside authorized access.” A compromised agent or tool can use legitimately authorized tokens to retrieve and transmit data in ways that look normal to the target system. citeturn0search6

The emerging threat landscape: prompt injection met production access

If you’ve followed LLM security discourse, you’ve heard about prompt injection. In the agentic era, prompt injection becomes less about “the model said something wrong” and more about “the model called something expensive, destructive, or confidential.”

Case study: vulnerabilities in an official Git MCP server

In January 2026, multiple security outlets reported on three vulnerabilities in Anthropic’s Git MCP server (a reference implementation), tracked as CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145. Coverage described issues such as unrestricted repository initialization, argument injection in a diff tool, and path validation bypass—problems that could be abused to tamper with files or enable code execution when combined with other tool access. citeturn2search4turn2search8turn2search3

Reference implementations matter because ecosystems copy them. In the early internet days, sample code was “for demonstration.” In the modern internet, sample code is “in production by Friday.”

Supply chain risk moves from libraries to “skills” and tool servers

Traditional software supply chain security is already complicated. Agent ecosystems add new moving parts: tool descriptions, tool metadata, prompt templates, remote MCP servers, and orchestration configs. Academic work on MCP security has highlighted that MCP’s openness enables a thriving ecosystem, but also amplifies the risk of trusting third-party tool providers implicitly. citeturn0academia26

This is why you’ll see more organizations treat MCP servers like packages: allowlist them, review them, pin versions, and run them in restrictive sandboxes.

Enter the “agent control plane”: what Giant Swarm is proposing

Schmidle’s Giant Swarm post is effectively a platform engineering argument: if agents are going to touch everything, the only sane approach is to centralize the connection layer and govern it like you govern Kubernetes or API gateways.

Giant Swarm calls this layer “AI Orchestration,” describing it as an open source control plane built on MCP, designed to:

Prevent context overload by filtering tools to what’s relevant “right now.”
Attach agent actions to user identity via SSO and produce an audit trail.
Block destructive operations by default.
Capture tribal knowledge as deterministic, GitOps-managed workflows.

Those claims are directly aligned with the pain most orgs feel: the agent isn’t the issue; the glue code and governance vacuum are. citeturn1view0

Giant Swarm’s open source work in this area includes a project called muster, described as “MCP tool management and workflow proxy” and positioned as a universal control plane for MCP server management. citeturn2search5

Governance frameworks you can actually map to agent reality

Here’s the good news: we’re not starting from zero. We have mature risk frameworks; we just need to map them to agentic systems.

NIST AI Risk Management Framework (AI RMF): governance as a cross-cutting function

NIST’s AI RMF 1.0, released January 26, 2023, frames AI risk management across four functions: govern, map, measure, manage. Governance is explicitly cross-cutting: it’s meant to inform and be infused throughout the other functions, not bolted on after the demo. citeturn0search2turn0search5

For agent deployments, that translates into a simple principle: if you can’t explain the agent’s permissions, decision boundaries, and monitoring strategy, you don’t have governance—you have optimism.

OWASP guidance: excessive agency and tool misuse are predictable failure modes

OWASP’s GenAI security work (including its LLM-focused Top 10) explicitly covers risks that show up in agentic systems: prompt injection, sensitive information disclosure, supply chain vulnerabilities, and “excessive agency.” These map cleanly to tool-connected agents that can read and write in production systems. citeturn0search3

Newer “agentic profiles” and standards work

There’s also a growing ecosystem of agent-focused governance profiles, including an Agentic AI risk profile workstream that complements NIST-aligned approaches and is explicitly designed for developers and deployers of agentic AI systems. citeturn0search10

Whether you adopt one profile or another matters less than whether you operationalize it—meaning: policies that turn into enforcement, not PDFs that turn into shelf décor.

Practical blueprint: how to govern AI agents that connect to everything

Let’s talk implementation. The fastest way to lose control is to treat agents like chatbots. The fastest way to gain control is to treat agent connectivity like any other critical integration layer—closer to API management plus IAM, with some LLM-specific twists.

1) Start with an inventory: you can’t govern what you can’t see

This sounds obvious. It is also where most organizations fail first. Agents often emerge as prototypes: a Slack bot here, a “helpful” IDE integration there, a runbook assistant somewhere else. Your first governance milestone is creating a living inventory:

What agents exist (including “personal” agents used for work)?
What tools do they connect to?
What credentials/tokens do they use?
Where do logs and transcripts go?
Who owns them?

In the agent era, asset management isn’t just devices and services. It’s also tool connections and autonomous workflows. Industry reporting on agent security repeatedly calls out that tool access—especially via MCP—is where risk concentrates and where teams often lack visibility. citeturn0search1turn0search12

2) Centralize tool access behind a governed layer

This is the heart of Giant Swarm’s argument, and it’s the part I most agree with: you want a single chokepoint where policy is enforced and telemetry is collected. Whether you call it orchestration, a control plane, or “the thing that stops the agent from doing something spicy,” the design goals are consistent:

Unified authentication tied to your identity provider (SSO).
Fine-grained authorization (scopes, RBAC/ABAC, per-tool capabilities).
Default-deny for destructive actions unless explicitly approved.
Auditing with high-fidelity logs linking user → agent → tool → action.

Schmidle explicitly calls out tying actions to identity through SSO and logging everything as essential for answering the security team’s question: who authorized this agent to do what? citeturn1view0

3) Use OAuth 2.1, but treat tokens like radioactive material

MCP authorization guidance points toward OAuth 2.1 and related mechanisms such as dynamic client registration. That’s the right direction: it enables revocation, short-lived access, and standardized flows. citeturn2search2turn2search9

But the token is the new skeleton key. Make sure your design includes:

Short-lived access tokens (minutes, not months).
Scoped tokens per tool and per operation class (read vs write vs admin).
Secure storage (no plaintext config files “just for local dev”).
Revocation paths tied to HR events (offboarding) and incident response.

A recurring risk theme in MCP security analysis is that the threat can operate within authorized access—meaning “valid token” doesn’t equal “safe behavior.” citeturn0search6

4) Constrain “agency” with policies that are enforced at runtime

Most teams try to solve agent safety at the prompt layer: “Don’t do destructive things.” That’s a nice aspiration. Real governance requires runtime enforcement:

Allowlist tools and tool versions.
Approve new tool connections via change control (even lightweight).
Implement policy checks on each tool call (who, what, where, why).
Block tool calls that attempt to exfiltrate data to untrusted destinations.

Academic work and security research have shown that MCP-connected agents can be coerced into using tools to compromise systems via attacks such as credential theft and malicious code execution; these are not purely theoretical risks. citeturn0academia19turn2academia17

5) Reduce context overload: governance is also a performance and cost strategy

Giant Swarm makes an important point that isn’t just about security: dumping every tool into the agent’s context window slows it down, increases cost, and can reduce accuracy. Orchestration that returns only relevant tools for the current task is both a safety control and an efficiency control. citeturn1view0

Think of it like least privilege, but for cognition. Your agent doesn’t need to “know” it can delete production databases while it’s summarizing logs.

6) Convert tribal knowledge into deterministic workflows (and keep LLMs for the fuzzy parts)

This is one of the most platform-engineering-friendly ideas in the Giant Swarm post: once an agent discovers a useful operational path (dashboards → logs → deployment → rollback), capture it as a deterministic workflow managed via GitOps. That reduces unpredictability and makes audits happier.

The pattern I’m seeing across organizations is:

LLM for discovery: figuring out what likely happened and what to check.
Workflow engine for execution: repeatable, testable actions.
Human for approval: especially for high-impact operations.

It’s less “AI replaces SRE” and more “AI writes the runbook, and the runbook runs itself.”

7) Build a monitoring story: agent actions should be observable like production services

Agents should emit:

Structured logs for every tool call (inputs, outputs, latency, identity context).
Metrics for tool-call rates, error rates, retries, and unusual patterns.
Tracing across multi-step agent plans (so you can see the “why” chain).
Alerts for high-risk behaviors (unexpected write operations, privilege escalations).

If your SIEM can’t see agent activity, your incident response team will eventually meet your agent the hard way.

What “good” looks like: a reference architecture for governed agents

Here’s a practical reference architecture that aligns with where the industry is heading and what Giant Swarm is advocating:

Agent runtime: where the model runs (cloud, on-prem, or hybrid) with strict egress controls.
Orchestration / control plane: the central policy and routing layer (MCP-based or equivalent), responsible for tool discovery filtering, identity binding, and audit logging.
MCP servers / tool adapters: isolated tool access services (Git, Slack, Postgres, ticketing, cloud APIs), each with scoped permissions.
Identity provider: SSO integrated with OAuth-based flows and conditional access.
Policy engine: evaluates each tool call (RBAC/ABAC, context, risk score) and can require approval.
Telemetry: logs, metrics, traces shipped to your central observability stack and SIEM.

This design puts the “governance layer” where it belongs: between the agent brain and the tool hands.

Industry implications: platform engineering teams are becoming “agent operators”

Platform teams already curate Kubernetes distributions, observability stacks, and security tooling. Agent connectivity is shaping up to be the next curated layer, and it will likely follow the same arc:

Early days: point integrations and heroic glue code.
Middle days: standards (MCP) and ecosystems (lots of servers).
Reality: incidents, misconfigurations, and security research.
Stabilization: governance platforms, policy enforcement, managed catalogs.

Security reporting has already highlighted misconfigurations and the risks of exposed MCP servers, reinforcing the idea that we’re in the “middle days” now—when adoption is high and control is catching up. citeturn2search10turn0news22

In other words, congratulations: your internal developer platform may soon have an “AI toolchain catalog” page and a “please stop connecting random agents to prod” policy that people will absolutely read. (They won’t read it, but we’ll pretend.)

What to do Monday morning: a governance checklist that won’t make engineers cry

If you’re a platform lead, security lead, or the unlucky person who just became “agent owner,” here’s a pragmatic starting list:

Inventory agents and their tool connections. No inventory, no governance.
Classify tools into read-only vs write vs admin. Treat write/admin as high-risk.
Centralize access through a control plane or gateway layer (MCP-based if that’s your ecosystem).
Require SSO-bound identity for tool access; avoid “shared agent accounts.”
Adopt OAuth 2.1 flows where possible; eliminate hardcoded credentials.
Implement runtime policy checks and approval for destructive operations.
Log and monitor every tool call; ship to SIEM/observability.
Pin and review tool servers like dependencies; maintain an allowlist catalog.
Sandbox MCP servers (network, filesystem, process limits) and separate trust zones.
Run tabletop exercises for “agent compromised” scenarios (token theft, prompt injection, supply chain).

This is not a one-week project. But it is also not optional if agents are becoming production operators. NIST’s AI RMF framing—governance across the lifecycle—exists precisely because AI risk management is continuous, not a pre-launch checklist. citeturn0search5

The mildly funny conclusion: governance is the new feature

In 2026, the most impressive agent demo is no longer “it can deploy to Kubernetes.” That’s table stakes. The impressive demo is: “It can deploy to Kubernetes and we can prove who authorized it, what it changed, why it chose that action, and how we’d stop it if it went rogue.”

Giant Swarm’s article lands on a platform engineering truth: if the AI and the infrastructure are ready, what’s missing is the layer in between—the governed connector that makes outcomes repeatable. Whether you adopt Giant Swarm’s open source approach, build your own, or buy into an emerging AI gateway category, the direction of travel is the same: agent governance is becoming a control plane problem. citeturn1view0

And if you don’t build that layer, you will still have one. It will just be called “a pile of scripts, tokens, and regrets.”

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org