If it is, there’s a big risk your governance is to.
Most Zero Trust projects don’t fail at the policy engine. They fail at what the engine reads.
The identity side of this is mostly solved. If you have run an IGA program over the past ten years, with SailPoint, Saviynt, Okta or Omada, you have lifecycle, attribute sync, recertification and audit trails for who your people are. When a policy checks someone’s employment status, department, role or clearance, it is reading data that is fresh, owned and audited.
The resource side is a different story. What is the classification of the document the policy just granted access to? Who owns the system that holds it? Which controls protect it? What contracts and dependencies sit underneath? In most organizations the answers live in spreadsheets nobody owns, in wiki pages last touched in 2022, and in the head of one architect who is about to retire.
The policy engine makes its decision in milliseconds. The data behind that decision was last checked eight months ago by someone who has since left. That is not Zero Trust. It is an old guess with a new login screen.
The two sides are not equal
Walk through a normal access decision and the gap is easy to see.
Jane is a senior analyst on your risk team. She opens a file in a shared workspace, and your policy engine checks the request. On Jane’s side, everything is current: she is employed, she sits in Risk and Compliance, she is a Tier 2 Risk Analyst, her clearance is Confidential, she did her annual training two weeks ago, and she passed MFA in this session. The engine knows Jane well, because IGA built the plumbing to know her.
On the file’s side, the engine knows almost nothing. The file sits in SharePoint. Its classification field is blank, because someone set it to “Internal” by default three years ago. Its owner is a mailing list with twelve current members and four people who have left but still get the mail. The system that holds it is listed in the CMDB under a name that no longer matches production. The controls that are supposed to protect it are described in a Word document in a different folder.
The engine sees none of that. It decides based on Jane and one stale tag on the file. Access granted.
This is not a flaw in Zero Trust as an idea. It is a flaw in what Zero Trust runs on. The identity side is mature and automated. The resource side is manual and scattered. One got twenty years of tooling. The other got spreadsheet.
The same gap, bigger, for service accounts
Service accounts make it worse. The non-human identity (NHI) space is busy right now. Astrix, Oasis, Entro and Token Security have raised real money on a simple point: machine credentials are governed worse than human ones. They are created in a hurry, owned by no one in particular, given access that grows over the years, and almost never retired.
That is true, and it is the problem those vendors are fixing. But look at which side they work on. They are catching the identity side up: what is this account, who owns it, what is it for, when should it be reviewed, when should it be shut off. Good work, and overdue.
The resource side gets even less attention. Take svc-erp-integration-prod, an account created in 2019 to push HR data into the finance system. Today it can read seventeen data sources and write to four, because every new integration added a little more. Its owner field points to a team that has been reorganized twice. Its password was last rotated in March, because someone happened to remember.
The engine knows the account logged in. Soon, with better NHI tooling, it may also know who owns it and when its access was last reviewed. What it still does not know: one of those seventeen sources now holds personal data covered by GDPR, two were reclassified as confidential after a review last quarter, and the finance system now falls under NIS2 because it supports a critical function. None of that is within the engine’s reach.
NHI tools answer the question “what is this account?” The question “and should it really be reaching all of that?” is a resource question. The first is being solved. The second is barely on the roadmap.
The same gap, faster, for AI agents
AI agents are the newest version of this, and the one where it turns dangerous fastest. In a matter of months, companies are running agents that read the wiki, query the ticket system, pull from chat, summarize documents, write code from internal material, and post answers back into all of it. Every one of those calls is an access decision. Every one passes through whatever policy engine sits in front of the data.
The identity side is starting to get sorted. The NHI vendors are moving into agent governance: who is this agent, who owns it, when is it reviewed, what is it allowed to do. Reasonable progress.
The resource side is where it breaks, and the stakes are higher now, because agents do not behave like service accounts. They read text, guess intent, follow instructions buried in the data they read, and act at machine speed. A planted line in a wiki page can turn into an instruction. A mislabeled document in a knowledge base can become the source the model leans on for next quarter’s advice.
Take an internal security assistant built on top of your control library. It can answer a question like “are we compliant with NIS2 Article 21?” Very useful, in theory. In practice, the control library was last updated by a team that has since moved on, the mapping to ISO 27001 is in one spreadsheet and the mapping to GDPR is in another, the evidence links point to pages that were never migrated, and three controls marked “implemented” are actually on hold pending a vendor change. The assistant reads all of that and gives a clear, confident, well-written answer. The answer is wrong.
Governing the agent’s identity is doable. Letting it reason over ungoverned resource data is a different problem. This is not really an access control failure. The machine just gave you a wrong answer, fast, and it sounded right.
Same problem, one cause
Three domains, three vendor categories, three sets of conference talks, and the same problem underneath. It does not matter much whether the engine making the call is Open Policy Agent, Cedar, AWS Verified Permissions, or a built-in layer in your IAM platform. The limit is the same: the engine can only reason over what it reads, and what it reads about resources is thin, old and unowned.
The cause is simple once you say it out loud. The IGA discipline, with its structured objects, governed attributes, lifecycle, ownership, recertification and audit, was built for one kind of thing: identities. It got two decades of investment, its own analyst category, its own tools and its own conference. It works.
That same discipline was never applied to the other things a policy engine needs to know about: information, processes, controls, requirements, frameworks, suppliers, contracts, assets, classifications and risks. Those live in nearby tools that each cover a slice, and none cover the whole.
GRC platforms tried, but they are built around forms and documents. They produce tidy reports for auditors. They do not hand governed attributes back to the systems that make decisions. A NIS2 dashboard in Stratsys, ServiceNow GRC or RSA Archer cannot be queried by your policy engine when an access decision needs to know whether the resource is in scope.
CMDB tools tried, but they stop at technical parts. They may know which server runs which application. They usually do not know what class of information that application handles, which processes depend on it, or which controls cover it.
Data catalogs tried, but they care about data quality and lineage. They are built for analytics teams, not for policy engines.
ITSM tools have the workflow muscle, but not the attribute discipline.
The thing that would tie all of this together, IGA-grade governance for everything that is not an identity, does not exist as a product category yet. Some companies have built pieces of it themselves, with custom databases and wiki pages and spreadsheets they rebuild every couple of years. Most have not.
That is why your Zero Trust strategy is stuck in a spreadsheet. Not because anyone is careless, but because the tool that would replace their favourite spreadsheet app for resource attributes is barely a category.
What it would take to fix it
The fix is not another policy engine. You probably have one that works. The fix is to give it something better to read.
That means treating your resources the way IGA already treats your people. Information, systems, processes, risks, controls, suppliers and contracts become structured objects, not rows in a spreadsheet. Each one has an owner. Each one has a lifecycle, created, reviewed and retired, with a record of who did what and when. Classifications are set and kept current, not guessed once and forgotten. And the whole thing can be read by the systems that need it, at the moment they need it, instead of sitting in a report.
None of this competes with your IGA program. It is the same idea, pointed at the other half of the problem. You already govern who your people are. This governs what your people, your service accounts and your AI agents are actually reaching.
There is a short way to say it. You have IGA for identities. You need IGA for everything those identities touch.
With that in place, the earlier examples change. The engine checking Jane’s file can see a real classification, a real owner and the controls in place, because someone is responsible for keeping them right. The service account’s seventeen sources carry current classifications, so a decision can account for the GDPR data and the NIS2 scope. The AI assistant reads a control library that is owned and current, so its answer is one you can act on.
Before the next project
Before you fund the next Zero Trust initiative, the next NHI rollout, or the next internal AI assistant, ask one question: where will the resource attributes live? If the honest answer is “spreadsheet,” you have found the reason your policies feel like theater. The engine is fine. The data under it is not governed.
We built Helios on this idea: the same discipline IGA uses for identities, applied to information, risk, controls and the rest of the resource side, running on-premise and under your control. If you want to see what that looks like in practice, get in touch.
