The first question any AI governance team has to answer is also the hardest: how many models are running in production right now, and what are they. I've sat in rooms where the answer changed three times in an hour as different teams surfaced models the central registry didn't know about. A fine-tune in the data-science sandbox that is quietly serving a customer-facing feature. A third-party API that was added during a hackathon and never removed. An open-source model running in a container that was never registered. Every one of these is a security surface. Every one of them needs to be in a structured inventory. Griffin AI maintains that inventory as a typed graph. Mythos-class tools maintain it as whatever the last prompt happened to surface.
What a model inventory actually needs to track
A usable model inventory records each distinct model artifact with its base model, its version, its fine-tune history, its quantization, its license, its hosting environment, its traffic volume, its prompt configuration, its tool permissions, its evaluation results, and its owner. That is a ten-field object per row. Griffin AI stores each of these as typed properties on a model node, with edges to the datasets the model was trained on, the evaluation runs that scored it, the deployments that serve it, and the guardrails that protect it. A Mythos-class tool produces a summary that mentions the most prominent three or four fields and compresses the rest into narrative. The compression is lossy. Any question that depends on the compressed fields gets an unreliable answer.
Base models versus fine-tunes versus merges
A realistic enterprise AI landscape contains base models (Llama 3.1 70B, Claude Opus, GPT-4o), fine-tunes of those base models for specific tasks, merges of multiple fine-tunes, and distillations to smaller form factors. Each of these has distinct security properties. A fine-tune of Llama 3 trained on internal customer data has different risk surface from the base Llama 3. A merge that combines two fine-tunes inherits the vulnerabilities of both. Griffin AI represents each of these as a distinct node with edges expressing the derivation relationship, so you can traverse "show me every production deployment that derives from a model trained on customer PII." A Mythos-class tool collapses the derivation chain into a name and a version string, which is fine until you need to reason about lineage.
Version drift and the audit trail
Models change. A provider pushes a new version of an API model, a team redeploys a fine-tune with updated training data, a quantization gets swapped from Q4 to Q5. Griffin AI records each version transition as an event in the inventory, with the old state, the new state, the actor, and the timestamp. The audit trail is a time-ordered sequence of transitions, each with its own digest. A Mythos-class tool does not maintain state between sessions, so version history is reconstructed on demand from whatever logs happen to be in context. The reconstruction is usually plausible and sometimes wrong. For a regulatory audit, plausible is not enough.
Traffic and blast radius
An inventory that records models without recording traffic cannot support risk prioritization. A model that handles one request per day and a model that handles one million requests per hour are not equivalent risk surfaces. Griffin AI joins model inventory to traffic telemetry, producing a blast-radius score per model that feeds the risk prioritization algorithm. A CVE affecting a high-traffic model jumps to the top of the queue automatically. Mythos-class tools describe the model and describe the traffic, but they do not join the two into a quantitative prioritization signal. The engineer has to do that join mentally, which does not scale past a small number of models.
Tool permissions and agent systems
Modern agent systems expose tools to models — file read, database query, API call, code execution. Each tool permission is a privilege granted to the model, and the union of privileges defines the model's effective capability. Griffin AI inventories tool permissions as edges from model nodes to tool nodes, and each edge has a scope (read, write, execute), a resource target, and a policy. You can ask "show me every model with write access to production databases" and get a graph answer. Mythos-class tools describe tool permissions in prose, which means questions about privilege minimization turn into reading comprehension problems. When an agent is later compromised, the question "what could it have done" has a structured answer only if the tool graph exists.
License compliance for models
Model licenses are more varied and more restrictive than typical software licenses. Llama has acceptable-use restrictions. Mistral has commercial license gradients. Many open-weights models have training-data-restriction clauses. Griffin AI normalizes model licenses against a reference table and evaluates license compatibility across the inventory. A deployment that uses a model license prohibiting specific commercial uses triggers a compliance finding. Mythos-class tools describe the license in prose and do not enforce compatibility. The compliance failure is quiet and expensive.
Hosting environments and supply chain for inference
The inference environment is part of the model's supply chain. A model served via vLLM on A100s at cloud provider X has different integrity properties than the same model served via TensorRT on H100s in a colo. Griffin AI records the inference environment as a structured property of the deployment node, with edges to the runtime version, the hardware type, and the hosting provider. This lets you reason about environment-level CVEs — a vLLM vulnerability affects every deployment running vLLM, and the inventory can enumerate them. Mythos-class tools treat the environment as descriptive context and do not maintain the cross-deployment join that makes environment-level reasoning possible.
Guardrails and prompt configurations as inventory
A model without guardrails is a different product from the same model with guardrails. Griffin AI treats guardrails — the prompt-injection filters, the output classifiers, the content moderation layers — as first-class inventory items linked to the models they protect. Prompt configurations are similarly inventoried with version history. A model whose guardrails were disabled yesterday is not the same model that was evaluated last month. Mythos-class tools rarely distinguish guardrail configurations from the underlying model, which means a regression in guardrail coverage is invisible to the tool's risk assessment.
Cross-product model reuse
In large tenants, the same base model is usually served in multiple products. Griffin AI's inventory reflects this as a shared node with multiple deployment edges, so a CVE in the model (or in its inference stack) surfaces automatically in every product using it. Mythos-class tools that produce per-product summaries miss the cross-product join and force manual correlation. The MOVEit campaign of 2023 is the software-supply-chain analogue — one component, many affected products, and only the tools with structured cross-product inventories could enumerate the blast radius in minutes rather than days. Model inventories face the same dynamic.
Shadow models and the enumeration problem
Shadow models — those not registered in the central inventory — are the hardest class of AI supply chain risk. Griffin AI's ingestion pipeline combines signals from container manifests, API traffic patterns, SCM imports, and MCP server registrations to surface candidate shadow models for review. Each candidate appears as a provisional node in the inventory until confirmed or denied by a human reviewer. Mythos-class tools, lacking an inventory persistence layer, cannot accumulate shadow-model signals across time and therefore surface them only during the session in which they happen to be mentioned.
What to verify this week
Pull every model deployment surface from your environment — registered models, cloud AI services with active traffic, containers with AI runtimes, SaaS integrations with AI features. Ask your AI security tool to produce a structured inventory with the ten fields above per row. Compare against ground truth. Griffin AI will produce a row-for-row match with high coverage. Mythos-class tools will produce a prose approximation that is right on the models it happens to name and silent on the ones it doesn't. The gap between prose and rows is the gap between governance and theater.
Inventory is the foundation
Every other AI security control — access review, patch management, incident response, compliance reporting — depends on the inventory being correct. A structured inventory with typed fields and time-ordered state transitions is the architecture that makes those downstream controls work. Griffin AI was designed around that foundation. Pure-LLM tools were designed around the surface above it.