Nobody hedges every position equally. You hedge where the exposure is — and most AI governance programs are hedging the org chart, not the book.
Why the Estate Map Matters Now
Every agent governance program starts with the same question: where do we begin? And almost every program answers it the same wrong way — by policy taxonomy, by regulatory checklist, or by whichever stakeholder shouted loudest in the steering committee. Finance gets governed first because the CFO asked. HR gets a policy because a workshop said “sensitive data.” Meanwhile the estate itself — the actual population of agents, apps, and connectors reading your data right now — never gets a vote.
That was survivable when the estate was small. It isn’t anymore. Gartner’s CIO survey has 17% of CIOs already running AI agents in production and 42% deploying within the year, and the guardian-agent budget line is projected to grow from under 1% of agentic AI spend today to 5–7% by 2028. The scope decision you make this quarter determines whether that budget lands on the domains that are actually hot or the ones that were politically warm.
| Signal | Value | Source |
|---|---|---|
| CIOs with agents deployed / deploying within a year | 17% / 42% | Gartner CIO survey |
| Endpoints surfacing at least one unsanctioned agent | 88% | Ospiri research |
| Median cost of an agent-related incident | +$670K | Ospiri incident modeling |
| Guardian-agent share of agentic AI spend by 2028 | 5–7%, from under 1% today | Gartner |
The estate map inverts the scoping exercise. Instead of asking “what should we govern?” in a conference room, you measure which data domains and applications your agents actually touch, rank them by traffic and footprint, and treat that ranking as a demand signal. Standardize, staff, and enforce where the demand is — the same way a trading desk allocates risk capital to the positions carrying the exposure, not the ones with the best slide deck.
Scope by Policy vs. Scope by Estate
Let’s step back. The two approaches look similar on paper — both end in a prioritized list of domains. They diverge on where the list comes from.
| Dimension | Scope by policy | Scope by estate |
|---|---|---|
| Input | Regulatory checklists, stakeholder interviews | Measured agent traffic and data footprint |
| Ranking logic | Perceived sensitivity | Realized exposure: which domains agents touch, how often |
| Ownership model | Follows the org chart | Follows the exposure |
| Refresh cadence | Annual policy review | Continuous — the map updates as the estate moves |
| Budget conversation | “We believe these areas are risky” | “These six domains carry 80% of agent access” |
| Failure mode | Governing cold corners while hot ones burn | Requires instrumentation you may not have yet |
The last row is the honest one. Scope-by-estate has a prerequisite: you need observability over the estate before you can rank it. But that prerequisite ships in weeks, and it pays for itself in the first budget meeting — because whoever holds the map wins the budget conversation. “These six data domains carry 80% of agent access” is a decision. “We think finance is sensitive” is a philosophy.
How Scoping by Committee Fails
The committee-scoped program fails in a predictable sequence:
- The loudest stakeholder sets the scope. The first governed domain is the one with the most senior sponsor, not the most agent traffic. Six months of control engineering lands on a domain three agents touch.
- The hot corners stay dark. The engineering file shares, the shared-drive exports, the connector-riddled ops workflows — high-traffic, low-glamour domains that no one sponsors — accumulate ungoverned agent access.
- Ownership fractures on contact. Because scope was assigned by org chart, the domain owner on paper isn’t the team whose agents create the exposure. RACI debates stall the rollout in pilot.
- The map gets built anyway — by the incident. The first serious agent incident produces, in the post-mortem, exactly the traffic-ranked domain analysis the program should have started with. You pay +$670K in Ospiri’s modeling for a document you could have generated in week one.
The Domain Heat Score
The ranking doesn’t need to be exotic. Score each data domain the way you’d mark a position:
Domain Heat = (Agent Traffic × Data Sensitivity) + (Access Grants × Drift Rate)
| Factor | What it measures | Where it comes from |
|---|---|---|
| Agent Traffic | Distinct agents touching the domain, weighted by action frequency | Endpoint observability |
| Data Sensitivity | Classification tier of the data in the domain (NPI, PHI, source, financials) | Existing labels — Purview/MIP where you have them |
| Access Grants | Standing credentials, OAuth scopes, and connector permissions into the domain | Identity provider + connector inventory |
| Drift Rate | How fast the domain’s agent population changes month over month | Map deltas — the refresh is the signal |
Sort descending. The top of the list is where you standardize tooling, assign a named owner, and write the first enforcement policy. The bottom of the list is where you consciously accept risk — which is a legitimate decision when it’s made looking at the number rather than in the dark.
Building the Map: Declared Plus Observed
So, what feeds the map? Two layers, and you need both.
| Layer | What it gives you | What it can’t |
|---|---|---|
| Declared footprint | Watermarks, skills files, and MCP manifests captured at publish — owner, intended data sources, requested scopes | It’s a self-report, frozen at publish time |
| Observed ground truth | Kernel-level record of what each agent actually opened, spawned, and sent | Doesn’t know intent or business context |
| Reconciliation | The drift between declared and observed — the highest-signal risk indicator in the estate | Requires both layers running |
The declared layer makes the estate legible; the observed layer makes it honest. An agent whose declared footprint says “reads the marketing wiki” and whose kernel trace shows it opening the payroll repo has just self-selected into your top governance priority — no committee required. That reconciliation is the agent governance program’s flywheel: the map ranks the domains, enforcement generates ground truth, ground truth updates the map.
And ownership follows exposure. When the map shows that a domain’s agent traffic comes overwhelmingly from one business unit, that unit’s leadership takes the R in the RACI — with a dotted line to the AI leader — because they own the behavior generating the risk. The org-chart debate that stalls most programs resolves itself when the data picks the owner.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Stand up estate observability across the enterprise endpoint fleet | Raw agent-to-domain traffic data | 1–2 weeks |
| 2 | Score every data domain with the Domain Heat formula | Ranked heat map, top-ten list | 1 week |
| 3 | Assign ownership by exposure — R goes to the BU generating the traffic | Signed RACI for the top five domains | 2 weeks |
| 4 | Write and deploy the first enforcement policy on the #1 domain | Live policy plus kernel evidence trail | 2–3 weeks |
Twelve weeks, one governed domain, and — more valuable than either — a map the next twelve weeks can be planned against.
The Bottom Line
Govern the domains your agents actually touch, in the order the traffic says, and let ownership follow exposure instead of the org chart. The estate map is not a compliance artifact; it’s a demand signal, and the programs that treat it that way put their budget where their risk is while everyone else is still scheduling steering committees. The map is buildable in weeks from artifacts you already have — declared footprints at publish, kernel ground truth at runtime — and it converts the least tractable governance question, “who owns this?”, into an empirical one.
If your team is sizing an agent governance rollout for this budget cycle, request a working session. We will walk through your environment, build the first cut of your domain heat map from live estate data, and scope a deployment. It takes 90 minutes.