Let employees build agents on every platform you own, and soon you’ll have more agents than anyone can name.
Each build platform keeps its own inventory, usage data, and risk view, so governance splits along the same lines. The collaboration admin governs collaboration agents, the low-code admin governs low-code agents, and the identity, data, and security teams each work alone. That arrangement holds until agents start calling each other, running unattended, and holding their own identities. After that, nobody sees the whole system.
Agents are a new kind of asset, but managing them uses skills IT already has: inventory, identity, access control, lifecycle, and risk. Your best agent admins are probably running your collaboration and identity platforms today.
Start with a registry Link to heading
Build the inventory before the approval workflows. Approvals on top of a partial inventory only cover the agents that were polite enough to register.
The registry should be the one authoritative inventory, and each field should answer a question you’ll ask later:
- Owner and team, so you know who answers when it breaks and who inherits it when the owner leaves.
- Build platform and native ID. Together they’re the key for matching the registry against each platform’s own inventory. Native IDs are unique only within their platform, so an ID alone will eventually collide.
- Where it’s published and who can discover and use it, which bounds the blast radius.
- Lifecycle state, because drafts and published agents need different rules.
- Whether a user or the system created it. System agents have their own lifecycle, and you don’t want them flagged as orphans.
- What it can call: connectors, tools, knowledge sources, and other agents. The risk check and the dependency count below both need this field.
Registration should happen without anyone remembering to do it. Built-in platforms register natively, and third-party platforms register through an SDK. Pro-code agents get a real workload identity, which lets you attach conditional access to the agent and revoke it when the agent retires.
Without a registry, you get agents that keep running after their owners leave, shadow agents nobody knows about, and no reliable answer to “how many do we have?”
Reconcile before you trust it Link to heading
Diff a new registry against every inventory you already have, in both directions. Agents a platform knows about but the registry doesn’t are shadow agents. Agents in the registry that no platform knows about are ghosts.
Run the diff on a schedule and watch the shadow count. If it doesn’t trend toward zero, something is creating agents outside the registration path, and that’s what to fix.
Coordinate instead of centralizing Link to heading
Don’t appoint an agent czar to take over every platform. The platform admins already have the expertise, so leave it with them. Give every team the same view of the registry and define the handoffs between them. One workable split:
- The AI admin owns tenant-wide inventory and lifecycle and connects the other teams.
- The agent identity admin provisions and deprovisions agent identities and writes identity-based policy.
- Security, compliance, and governance decide which data, tools, and permissions agents may request, what counts as risky, and which approval tier applies.
An agent blueprint helps here. It’s a portable spec of an agent’s identity, capabilities, constraints, policies, data access, and lifecycle, and it gives those three roles one document to argue over.
Check risk at build time and run time Link to heading
At build time, look for broad permissions, insecure config, and missing responsible-AI safeguards. At run time, look for unexpected data exposure, prompt injection, and protections that fall away as data moves between systems.
The pattern to hunt for is an agent that can read sensitive data and write somewhere broadly readable. That’s an exfiltration path.
Per-agent review catches the case where one agent holds both halves. It misses two agents that each pass review alone, and that case gets more common as agents multiply. Say one agent reads the HR database and writes nowhere, and another posts to an all-hands channel and reads nothing sensitive. When the second calls the first, both approvals were correct and the pair still leaks.
Data crosses a call in both directions, since arguments go down and results come back up. So the check is reachability over an undirected call graph, from anything that reads sensitive data to anything that writes broadly. In Rego:
package agents.risk
import rego.v1
sensitive := {"confidential", "restricted"}
broad := {"org", "public", "anonymous"}
agents := {a.name: a | some a in input.agents}
reads_sensitive(a) if {
some r in a.reads
r.label in sensitive
}
writes_broad(a) if {
some w in a.writes
w.audience in broad
}
callees(name) := {n | some n in agents[name].calls}
callers(name) := {m | some m, b in agents; name in b.calls}
linked[name] := union({callees(name), callers(name)}) if {
some name, _ in agents
}
# [source, sink]; source == sink when one agent holds both halves.
exfil_path contains [src, dst] if {
some src, a in agents
reads_sensitive(a)
some dst in graph.reachable(linked, {src})
writes_broad(agents[dst])
}
It returns the single-agent case and the composed ones, including chains that run through a router agent that touches no data at all.
The check over-approximates, because a call edge shows that data can flow without showing that it does. That’s the right error for triage, since every result is a path someone should prove safe. Any new agent can connect two old ones, so run the check whenever an agent registers.
Set the sensitivity labels and the definition of “broad” with security, privacy, HR, and legal in the room.
Pull signals from identity, data protection, and threat detection into one view so teams can prioritize, then fix each problem in the tool that owns it. A separate security workflow built around agents would leave you two sources of truth to keep in sync.
Govern by exception Link to heading
Manual review stops working long before you reach thousands of agents. Let guardrails, a standard development lifecycle, and risk-based policy decide which agents need a human, and handle the rest in bulk with rules keyed on permissions, connectors, owner status, and usage. Use the UI for decisions that need judgment and the API to apply changes.
Ownerless agents make a good first rule. If the owner has left and nobody has used the agent in a month, disable it. If people still use it, reassign it to the team, since someone depends on it. Disable before you delete, so a surprised team can get its agent back.
Make each dashboard end in a decision Link to heading
A dashboard should surface the cases where someone needs to act. Retire or reassign ownerless agents, as above. Tell near-identical duplicates apart by usage and connections. Look closer at fast risers, since sudden adoption can mean value or risk. Scale high-impact agents deliberately.
To decide where to look first, count how many agents rely on each connector, tool, and knowledge source. The ones at the top of that list have the largest blast radius. If one breaks or leaks, every agent that depends on it goes with it.
Keep the governance view separate from adoption analytics, because they answer different questions for different people. And don’t hold a weekend experiment to the same process as a business-critical agent.
Hold a weekly review Link to heading
The technical work here is manageable. Getting IT, security, identity, product, and business teams into a weekly review, looking at the same data and deciding together, is harder. Start that meeting before agent growth outruns it. Once it has, the meeting spends its time on incidents.
New agent types and build tools will keep arriving, so treat this operating model as version one and expect to revise it.