Governing Customer-Owned Agents: Control-Layer Patterns for Mixed Agent Fleets

The instinct is to govern each agent where it runs: give the vendor agent its own service account, hope its sandbox holds, and trust its vendor's safety claims. That model fails for structural reasons, and the industry data explains why it fails harder every quarter.

Roughly 41% of codebases are now AI-generated, and around 45% of AI coding tasks introduce a critical flaw or security issue. An agent is, in effect, a fast machine-author of changes, so a fleet of them concentrates that defect rate and points it directly at production. When the author is a third party, you cannot review the code that produced the change, only the change itself. And behavior makes it worse: about 80% of developers bypass policy or guardrails when those guardrails add friction. A vendor's agent has even less incentive than your own engineers to respect a policy that lives in a document rather than in the system.

The deeper issue is that per-agent trust does not compose. Ten agents, each "reasonably safe" in isolation, produce a combined blast radius nobody scoped. Two agents can race on the same resource. A vendor agent can satisfy its own success criteria while violating yours. Trust placed in individual agents cannot be aggregated into trust in the fleet. You need a single point where authority is decided for all of them, on the same terms.

Before authorization, you need to know who is acting. In a mixed fleet, "who" is the hardest part, because the actors are non-human, ephemeral, and partly external.

Treat every agent as an untrusted workload that must prove its identity before it does anything. That means no ambient credentials, no shared service accounts, and no long-lived API keys passed to a vendor and forgotten. Each agent, yours or theirs, presents a short-lived, attested credential bound to a specific identity, and the control plane records which agent took which action under which identity. This is the difference between an audit trail that says "the integration account modified the provisioning config" and one that says "vendor agent X, instance 7, acting under a credential issued at 14:02 and valid for nine minutes, proposed this change."

Two non-negotiables for telecom specifically:

Once identity is established, the control plane decides what each agent may do. The wrong axis is "how much do we trust this vendor." The right axis is capability scoped to blast radius: what can this specific agent touch, and what breaks if it is wrong?

This is where a live System Graph becomes the substrate for governance rather than a nice-to-have map. Because it models services, dependencies, and CI/CD as one change-aware graph, the control plane can answer the question that actually predicts risk: does this proposed action touch a node that fans out to a subscriber-facing path, a billing system, or a regulated data store? Capability is then granted against the graph, not against a vendor's reputation.

Make capability grants explicit and narrow:

The control plane unifies this. Governance is where capability grants, policy checks, and the audit trail live as configuration that applies identically to a Zof-managed agent and a customer-owned or vendor one. One policy surface, many agents, no per-vendor side deals.

Here is the move that lets you govern agents you cannot inspect: stop judging agents by who built them, and judge every proposed change by the evidence attached to it. A change from your own agent and a change from a vendor's agent reach the gate carrying the same required artifact, what was exercised, what regressed, what the reachability analysis says about exposure, and the gate decides on that, not on pedigree.

This is only credible if the validation is real and change-aware. Coordinated Testing Fleets plan and execute validation against what actually changed and what depends on it, rather than running a static suite that ignores the dependency graph and proves nothing about the specific diff. For security gates, reachability matters: asking whether a flaw sits on a path that is actually reachable in your deployed system, rather than triaging every theoretical finding, can mean 70 to 90% less exploitable exposure. Applied to a mixed fleet, a vendor agent's change that introduces an unreachable issue does not have to block a release, while a reachable one routes straight to a human. You spend scarce review attention on real risk, regardless of which agent surfaced it.

Crucially, this equalizes incentives. A vendor agent cannot declare its own work complete and merge. It produces a proposal with evidence; your control plane decides. Agents propose, humans authorize, and the principle holds whether the proposer is on your payroll or your supplier's.

A mixed-fleet control plane introduces its own ways to fail. Name them so your design accounts for them.

When a vendor agent must run where your data cannot leave, inside a network operations boundary or a regulated enclave, keep the authority model intact by moving the runtime, not the trust. Edge Runners execute as signed capsules inside your perimeter and emit audit-ready evidence outward, so the data stays put and the proof comes to you. Remediation is the part to govern hardest; letting any agent, yours or a vendor's, fix a production network unsupervised is reckless, which is why governed Remediation Fleets keep apply behind the same authorization as everything else.

### What to do Monday morning