- Praveen Kumar
In a cycle dominated by agent demos and orchestration frameworks, Jaya Gupta and Anshu Garg at Foundation Capital articulated a point that the industry has largely missed: agents don’t fail because they lack intelligence, they fail because they lack context. Specifically, the context behind decisions : why something happened, which exceptions applied, who approved what, and how reasoning unfolded over time.
Their “context graphs” thesis reframes the AI opportunity away from building ever-smarter agents and toward building the substrate that allows agents to operate reliably, explain decisions, and earn trust. It’s a needed correction in a market that’s moved faster on abstractions than on foundations, and it echoes a familiar pattern from the last AI/ML wave, where data quality and grounding proved more decisive than model sophistication.
It’s a powerful thesis, and directionally correct. But in the security ecosystem, there’s a critical prerequisite that comes even earlier.
Before decision context can exist, enterprises must first establish operational context – a shared, consistent, cross-tool understanding of identities, systems, enforcement, and change. Without it, agents are left reasoning on incomplete and unsafe inputs, no matter how advanced they appear.
The missing layer in security AI
Security environments are uniquely fragmented:
- Dozens of tools across IAM, EDR, cloud, AppSec, SaaS, and GRC
- Each tool has its own schema, identity model, and notion of “truth”
- No single system actually represents the enterprise’s security reality
As a result, when we ask questions like (to whosoever – AI systems or humans)
- Is MFA enforced across all users?
- Do we have orphan identities?
- Which SaaS apps bypass SSO?
- What changed that put this audit control at risk?
The answers are rarely direct. They require correlating facts across systems, reconciling identities, understanding coverage gaps, and reasoning over time.
This is not “decision context” yet.
This is operational context and most enterprises don’t have it.
Why decision context can’t exist without operational context
The Foundation Capital article argues that future systems of advantage will capture decision traces: the reasoning, approvals, exceptions, and policies behind outcomes.
That’s absolutely true.
But in security, decision traces are meaningless if we don’t first have answers to basic operational questions:
- Who is this identity, really? (across IdP, SaaS, cloud, code)
- What systems exist, and which ones matter?
- What is actually enforced vs. merely configured?
- What changed, when, and where?
If those facts aren’t well-defined, then higher-order context (e.g. controls, policies, approvals, exceptions) rests on shaky ground.
In other words:
You can’t build “why” until you’ve stabilized “what is true.”
Security agents expose this gap immediately
Agentic AI makes this problem impossible to ignore.
Agents don’t struggle because they lack intelligence.
They struggle because they lack shared, reliable context.
An agent asked to “validate access controls” or “prepare audit evidence” immediately runs into:
- conflicting user lists
- inconsistent MFA enforcement
- partial SaaS coverage
- stale or unverifiable evidence
Without a common operational context, agents either:
- hallucinate relationships, or
- require excessive human intervention, or
- become unsafe to automate
This is why operational context is not optional in security AI, it is foundational.
What “operational security context” actually means
Operational context is not another data lake or log store.
It is a continuously derived, cross-tool understanding of the enterprise’s security posture, grounded in objective facts:
- Canonical identities and their representations across systems
- Actual enforcement state (not just policy intent)
- Coverage gaps and exceptions
- Time-aware snapshots of configuration providing freshness and continuity
- Evidence that can be replayed, explained, and audited
Crucially, this context must be:
- Derived, not manually curated
- Cross-domain, not tool-specific
- Governed, so automation is safe
- Consumable by agents, not just humans
Unlike legacy approaches that rely on manual data entry or static CMDBs, which are often out of date the moment they are created – true operational context must be generated automatically from the live environment. By supporting modern protocols like the Model Context Protocol (MCP) and agent-to-agent interfaces, this layer becomes the essential infrastructure for an environment where AI systems can autonomously consume ground truth they can trust.
This is the layer that security has been missing.
How Unizo is building this operational context
At Unizo, we’re deliberately building the operational security context layer first, before aspiring to decision graphs or higher-order reasoning.
Our approach is simple in principle, hard in execution:
- Connect to the enterprise toolchain
Using a unified API and data fabric, we connect to identity, SaaS, cloud, AppSec, endpoint, and GRC-adjacent systems without forcing customers to normalize or manage integrations themselves. - Normalize and stitch security facts
We resolve identities across systems, link systems to enforcement points, and correlate posture signals across domains. - Derive decision-ready security signals
Instead of exposing raw data, we expose facts that matter, such as:MFA enforcement coverage
Orphan and dormant identities
SaaS apps without SSO
Privileged access drift
Evidence freshness and continuity
- Govern access and automation
Every query, signal, or proposed action is subject to policy, approvals, and audit, so agents can operate safely in real environments. - Expose context via APIs, agents, and events
The same operational context is accessible through REST APIs, webhooks, and modern protocols like MCP (Model Context Protocol) tools. By supporting agent-to-agent interfaces, we enable a machine-to-machine economy where GRC platforms, SOC tools, and internal AI systems can autonomously consume shared infrastructure they can trust.
We intentionally do not define controls, frameworks, or compliance outcomes. Those belong to higher layers.
Our role is to ensure that when those systems reason, they’re reasoning over ground truth.
Operational context - foundation for everything that comes next
The Foundation Capital article is right: context graphs and decision systems will be enormously valuable.
But in security, they only work if they’re built on a solid base of operational context – one that spans tools, identities, systems, and time.
Unizo is building that base.
Not as a dashboard.
Not as a GRC platform.
Not as a SOC copilot.
But as shared infrastructure: the enterprise security context layer that agents, platforms, and teams can trust.
Because in security, before we can automate decisions, we must first agree on reality.
FAQs
1. Is Unizo a GRC or compliance platform?
No. Unizo does not define controls, frameworks, policies, or compliance outcomes. Those belong to GRC platforms. Unizo provides the operational security context – objective facts about identities, systems, enforcement, and change. GRC platforms depend on that to reason accurately and automate safely.
2. Is this about building AI agents or copilots?
No. This is not about building agents. It’s about building the context layer that agents and humans need to reason safely. Agents are consumers of operational security context, not the product itself.
3. Where does Unizo sit in the enterprise architecture?
Unizo sits between enterprise security and IT tools (identity, SaaS, cloud, AppSec, endpoint, GRC-adjacent systems) and the systems that need to reason about them – humans, platforms, workflows, and AI agents. It acts as shared infrastructure rather than an end-user application.
4. Is Unizo an AI SOC or SOC copilot?
No. Unizo does not perform detection, triage, or response. Instead, it provides the operational context – identity resolution, enforcement state, coverage gaps, and time-aware evidence that AI SOCs rely on to reason correctly and automate without risk.
5. How is this different from SIEMs, data lakes, or security data platforms?
Those systems aggregate data, logs, or events. Unizo derives context reconciling identities, enforcement, systems, and change across tools to establish what is actually true. The output is decision-ready security facts, not raw telemetry.
6. Who is this relevant for today?
Unizo is relevant for:
Security and GRC product builders adding AI or automation
Enterprises building internal security copilots or agentic workflows
Platform teams standardizing security evidence and posture across tools
The same operational context can serve multiple use cases and stakeholders.
7. What is the difference between "Operational Context" and "Decision Context"?
Operational Context is the “ground truth” of your environment – a shared, consistent understanding of identities, systems, and actual enforcement states. Decision Context is the higher-order reasoning behind outcomes, such as policies, approvals, and exceptions. In security, you cannot reliably build the “why” (Decision) until you have stabilized the “what is true” (Operational).
8. Why can't LLMs or AI agents derive this context themselves?
Agents struggle not because they lack intelligence, but because they lack a shared, reliable substrate to reason over. Without a common operational context, agents either hallucinate relationships, require excessive human intervention to verify facts, or become unsafe to automate entirely.
