Enterprise AI has outrun the asset inventory. Agents, models, MCP servers, vector stores, pipelines, and the non-human identities that connect them are being deployed faster than any inventory process was designed to track. Most of them arrive the same way ordinary software does: through a repository, a build, or a cloud service. Very few arrive through a security review.
That leaves security leaders holding a set of questions they cannot answer with evidence. Denali, part of Transilience AI’s product range from Network Intelligence, was built to answer them.
Four questions most security teams can’t answer today
Which AI systems do we actually run? Not which ones were approved, but which are live in production right now, in which account, from which repository, at which revision.
What can they reach? Which identities, data stores, tools, and workloads a given agent or model is connected to, and which of those connections matter.
How do we know? Whether a claim on a dashboard is an observed fact, an inference, or a conclusion the product assembled, and whether it can be defended to an auditor or a board.
What did we miss? Which parts of the estate were never collected, failed collection, or sit out of scope, instead of being quietly counted as clean.
Cloud posture tools describe the infrastructure an AI system runs on, not the AI system itself. Model registries describe models but not the identities and data around them. Scanners produce findings, but a finding is not an asset, and a list of findings is not an attack path.
What Denali is
Denali is an evidence-led, provider-neutral AI security platform. It builds a living inventory of the AI systems an enterprise runs, traces how they connect, and keeps observed facts, inferred relationships, security conclusions, and coverage limits permanently separate. It is open source under the Apache License 2.0, and it is a standalone product rather than an extension of a cloud security posture tool.
The short version: it is an evidence layer for AI systems, not another score. A product can always render a confident-looking number. The harder engineering problem, and the one that decides whether a security program can rely on the output, is keeping every number traceable to something that was actually seen.
Three principles the product is built on
Evidence before verdict. Observed facts, inferred relationships, and security conclusions are separate objects. Inventory is not a finding, a finding is not an issue, activity is not a detection, and none of them automatically becomes a risk verdict or a confirmed incident. Every claim can be opened, reviewed, challenged, and defended.
Coverage before counts. Source coverage stays visible as complete, partial, failed, unsupported, or unknown. A failed or partial collection cannot withdraw previously observed inventory or resolve findings by absence, so incomplete evidence stays visibly incomplete instead of turning into an empty or safe-looking result.
Read-only by design. Onboarding grants only the documented read scope. Denali does not accept customer access keys, service-account JSON keys, personal access tokens, or cloud CLI sessions, and the customer keeps control of provider-side IAM and application installation state throughout.
What Denali discovers
The inventory spans 12 asset types: agents, applications, models, MCP servers and tools, guardrails, frameworks, pipelines, data stores, workloads, repositories, identities, and software components.
It draws on five connected sources: AWS, Microsoft Azure, Google Cloud, GitHub, and Microsoft Entra (collected through a separate Microsoft Graph connector). Beyond those, it can:
- Statically analyze source repositories, including Python, TypeScript, JavaScript, Terraform, Kubernetes YAML, and other infrastructure-as-code formats, and correlate code to the cloud resources it deploys.
- Observe MCP servers by initializing a connection and reading the tool list, without ever invoking a tool.
- Import external scanner output through OCSF, including Prowler findings, Syft SBOMs, and Grype vulnerability reports, as an interchange boundary that is never used to invent inventory.
Facts, findings, and issues kept apart
Denali’s surfaces reflect that separation on purpose. Inventory holds resources with evidence-backed relationships and per-resource assertions. Findings hold atomic configuration facts. Vulnerabilities are scanner-neutral and SBOM-first. Issues are assembled deterministically, and only from sufficient independent evidence. Runtime activity and evidence-linked detections sit alongside them. The result is that an attack path is something you can trace back to the individual facts that support it, not a conclusion you have to take on faith.
Read-only access, with the boundaries stated plainly
Source collection is tightly bounded. Repository access uses an organization-owned GitHub App scoped to exact repositories. Validation reads no source blobs. Collection resolves each repository to an immutable revision, applies hard tree, file, and byte limits, analyzes a temporary snapshot, then discards the token and source files.
One distinction is worth stating as plainly as the product does: a validated connection is not the same as a collection run. A healthy connection means the read-only entry points answered. It does not mean inventory exists yet, and the interface shows the two as separate boundaries. Collection is currently operator-run, and automatic scheduling after a connection validates is on the roadmap.
Try it before connecting anything
Denali offers two deployment shapes. The local evaluation stack runs on Docker Compose with PostgreSQL and seeds clearly labeled fixture data, so a team can inspect the evidence and coverage experience without providing any credentials. A hosted multi-tenant pilot runs for organizations ready to connect a real read-only scope, such as a single AWS account, a set of GCP projects, or a selection of GitHub repositories.
Where Denali fits
Denali is the first step of a connected loop. It answers what AI you run, how it connects, and what the evidence is. From there, Kamet tests whether what was found can actually be exploited under controlled autonomous testing, and Rainier detects, triages, and responds on the stack a customer already runs. More products are being built on the same foundation, so what one product surfaces becomes the input the next one acts on.
Who this is for
- CISOs and security leaders who are being asked about AI risk by a board or regulator and need an answer backed by evidence rather than a survey of what teams say they use.
- Cloud and platform security teams who need to see AI workloads, MCP servers, and agent identities that never went through a formal review.
- Governance, risk, and compliance teams who need to know which parts of the estate were and were not covered before signing off on a claim.
- Engineering and AI teams who want an inventory that traces code to cloud resources without asking for keys or tokens.
Want to see what AI is really running in your environment? Book a Denali walkthrough.
