// governance

An AI Bill of Materials your auditors can use — without logging a single prompt

Reference — Regulation (EU) 2024/1689 (the EU AI Act) In force since 1 August 2024, with obligations phasing in through 2026. The provisions an AI inventory speaks to: Art. 12 — record-keeping & automatic logging · Art. 26(6) — deployers keep logs · Art. 13 — transparency & information to deployers · Art. 72 — post-market monitoring. Full text: eur-lex.europa.eu/eli/reg/2024/1689/oj

The EU AI Act asks you to know, and record, which AI systems you operate. Most tools answer that by scanning and storing your content. There's a cleaner way: an inventory built from configuration metadata, generated on the device, that never reads a token or a prompt.

What an AIBOM is — and why 2026 made it urgent

An AI Bill of Materials (AIBOM) is to your AI stack what an SBOM is to your software supply chain: a formal, exportable inventory of the AI assets in use — models and providers, the agents your developers run, the MCP servers those agents are wired to, and the local models sitting on disk. For a GRC or security team, it answers the first question every AI audit now opens with: what AI is actually running here?

The EU AI Act turned that from good hygiene into an obligation. Its transparency and record-keeping provisions — and the record-keeping/logging expectations around higher-risk uses — assume you can produce evidence of what you deploy and how it's governed. An AIBOM is the artifact that answers it.

The problem with how most tools produce one

Discovery usually means inspection, and inspection usually means egress: a cloud service that proxies your traffic, reads your prompts, and reconstructs your inventory from what it saw. To document that you handle sensitive data carefully, you route that sensitive data through another vendor. For a regulated or data-resident organization, that's the opposite of the assurance you were trying to produce.

MoorAI's answer: content-free, and on the device

MoorAI builds the AIBOM from configuration metadata only. It reads which model each agent is set to, which MCP servers are configured, which local models are on disk — and it infers each MCP server's capability scope (network / filesystem / credential access) from its launch config and environment-variable names. It never opens a credential file, never reads a token value, never touches a prompt. The output is asset names, counts, and risk levels — nothing else.

Run the agent, hand your auditors a bill of materials. The open-source MoorAI agent generates a device-level AIBOM standalone — no server, no account, nothing leaving the machine: 
npx moorai-aibom --format md   # Markdown for the report
npx moorai-aibom               # JSON for your GRC pipeline
npx moorai-aibom --format csv  # CSV

Exactly what it reads — and what it never touches

A security reviewer should be able to know precisely what an inventory tool looks at. The MoorAI agent reads configuration metadata only, from these files:

For each MCP server it infers capability scope (network / filesystem / credential) from the launch command, its arguments, and environment-variable names — for example, seeing a GITHUB_TOKEN key present tells it the server touches credentials. It never reads the value of that variable, never opens a credential file, and never reads a prompt or the contents of your source. The output is asset names, counts, and risk levels — nothing else. You can confirm all of this in the AGPL source, or run moorai-aibom --help for the same disclosure at the terminal.

What's in it

Across a fleet, the management console rolls these device-level inventories into a tenant-wide AIBOM plus EU AI Act usage-and-governance records — an append-only trail of who changed which policy and when, alongside content-free usage evidence. The console never receives prompt content either; the whole pipeline is content-free by construction, and because the agent is open source (AGPL), that's a claim you can verify rather than trust.

Honest about what it is

An AIBOM is records and evidence to support your governance and EU AI Act obligations — an inventory and an audit trail. It is not a certification, a conformity assessment, or legal advice, and it does not by itself make you compliant. It gives your auditors and your board something real to work from, produced without turning your developers' AI usage into a surveilled archive.

Get the community agent →

MoorAI — on-device guardrails for AI agents. Governance without surveillance. See also MoorAI overview and on-device AI DLP.

glick.run — AGPL-3.0