THE FIRST AGENT ONTOLOGY · OPEN-CORE · v0.1.0

Your agent can wire money and deploy code.
Which control answers for it?

Frameworks made agents powerful. Observability told you what they did. Nobody mapped who answers when an agent acts — until now. OpenAgentOntology reads your agent's code, policies, and specs (never executing them) and emits a signed ontology that maps every action to the control that governs it. One scan. Every framework. One receipt.

Speaks NIST 800-53 · EU AI Act · OWASP LLM Top 10 · MITRE ATT&CK — every action also carries the technique your SOC already hunts (T1059, T1048, T1485…).
python -m openagentontology your-agent-dir/
A NEW CATEGORY

What is an Agent Ontology?

A typed, signed map of every action an AI agent can take — and the governance control that answers for each one. This is the first one.

THE AGENT STACK HAS THREE LAYERS. THE INDUSTRY SHIPPED TWO.
FRAMEWORKS
LangChain · CrewAI · MCP — makes agents capable. Crowded.
OBSERVABILITY
LangSmith · OpenTelemetry — tells you what they did. Crowded.
AGENT ONTOLOGY
who answers for each action. Empty — until now.
COMPLIANCE-AS-CODE, FOR AGENTS

You know Compliance as Code — OPA, Chef InSpec, HashiCorp Sentinel, Checkov — proving your cloud config meets the rule. This is the same rigor for the thing the cloud now runs: autonomous agents. New surface, same proof.

WHY IT'S REMARKABLE

The org chart for your non-human workforce. The safety data sheet for autonomous software. The building inspection — not the smoke-detector log that fires after the breach.

Frameworks make agents powerful. Observability tells you what they did. The Agent Ontology tells you who answers.

Grounded in a live NICE × MITRE ATT&CK × O*NET control crosswalk, so every governed action also carries the ATT&CK technique your SOC already hunts. The map isn't guessed; it's retrieved.

THE SHAPE OF GOVERNANCE

Ontology structure

Agent Asserted control Inferred (confirm) Ungoverned Runtime operation
RAW OUTPUT

Live demo — the actual ontology

IDTypeNameProvenance
SourceRelationshipTarget
ActionMatched ViaFramework MappingsTo Assert
TRUST PROFILE

Scored posture

0 / 100
RATIONALE
    HOW A CONTROL IS RESOLVED

    Three layers. One verdict.

    Every action drops through three layers in order. The first that matches wins — and the layer it matched on becomes the confidence you can trust. Hardening an agent means pushing every action up to Layer 1.

    1
    ASSERTED TABLE

    The action declares a reason: that's a canonical deny key. Exact match. Full-confidence, auditable mappings.

    2
    HEURISTIC

    No declared reason. The label matches a strong verb, so controls are emitted but INFERRED — a guess you must confirm.

    3
    NO MATCH

    No reason, no verb. The action is UNGOVERNED. Empty mappings. Fix these first.

    FROM UNGOVERNED TO GOVERNED — ONE COMMAND

    CWN AgentFDE

    A human Forward Deployed Engineer scans your agent, finds the ungoverned actions, writes the policy gates, proves the tier moved, and hands off a report. AgentFDE does it autonomously — scan → triage → generate the governance → re-score → notarize → hand off. Deploy it against any agent, workflow, or policy set to make onboarding a single command.

    python -m openagentontology.fde your-agent-dir/
    41
    sample_agent — before, UNGOVERNED
    →
    AgentFDE writes governance.agent.yaml + governance.rego + a signed receipt
    88
    after, projected — HARDENED, +47

    It never runs your code. The generated manifest scans SOVEREIGN 96 on its own — real governance, not a stub. And AgentFDE itself is a governed agent (SOVEREIGN 94): the tool governs the tool that does the governing.

    ZML EXPLANATION

    What this is, in four lines

    Bottom Line

    OAO reads your agent's code, policies, and API specs — never executing them — and outputs a signed ontology that maps every action to the governance control that answers for it. One scan. Every framework. One receipt.

    So What?

    If your agent can wire money, deploy code, or export data, someone is liable when it misbehaves. OAO tells you which controls cover each action, which are only inferred (need human confirmation), and which are completely ungoverned (fix first). Toggle before/after above: declaring a canonical reason on every action moves the same agent from 41 to 93.

    What's True
    • 13 node types (Agent, Capability, Tool, Task, Decision, Policy, Gate, Evidence, Outcome, Resource, Domain, Workflow, Actor)
    • 13 edge types (OWNS, DELEGATES_TO, HAS_CAPABILITY, USES, EXECUTES, PART_OF, PRODUCES, MAKES, GOVERNED_BY, SUPPORTED_BY, ENFORCES, GATED_BY, OPERATES_ON)
    • 7 ingestion formats (Rego, OpenAPI, MCP, speckit, agentdef, Python AST, directory)
    • 3-layer crosswalk: ASSERTED (exact, auditable) → HEURISTIC (verb-based, confirm) → UNGOVERNED (no match, fix first)
    • 10 canonical deny reasons, 35+ control mappings across NIST 800-53, EU AI Act, OWASP LLM Top 10, NIST AI RMF, MITRE ATT&CK, OCSF, NICE
    • 4 trust tiers: SOVEREIGN (≥90), HARDENED (≥75), DEVELOPING (≥50), UNGOVERNED (<50)
    • Ed25519 signed receipt — verifiable from the certificate alone, no network call
    What You Need To Do

    Run the scan, read the trust profile, and declare a canonical reason on every ungoverned or inferred action.

    python -m openagentontology your-agent-dir/
    QUESTIONS A SKEPTIC ASKS

    FAQ

    How is this different from OPA (or any policy engine)?
    OPA enforces policy at runtime — it's the gate that returns allow/deny. OpenAgentOntology maps your agent's actions to the controls that should govern them and shows which ones have no gate at all. OPA is the lock; OAO is the audit that walks the building and finds the doors with no lock — then translates each into NIST 800-53, EU AI Act, and OWASP so your auditor, regulator, and board each read it in their own language. They compose: OAO ingests your .rego as input, and an action behind an OPA gate with a canonical deny reason scores ASSERTED. OAO doesn't enforce anything; it tells you where enforcement is missing.
    How is this different from tracing / observability (LangSmith, OpenTelemetry)?
    Tracing tells you what your agent did on a given run. OAO tells you — statically, from the source, before it runs — what it can do and which control answers for each action. Observability is the flight recorder; OAO is the pre-flight inspection that maps every control surface.
    Does it run my agent's code?
    No. It parses source as an AST and reads text — it never executes anything, and the core pipeline makes no network calls. Nothing you point it at runs. The receipt is signed locally.
    "Inferred" sounds like guessing — why should I trust it?
    Because it's labeled as a guess. A verb heuristic (send_* → egress controls) is tagged INFERRED so you confirm it; only an exact, declared canonical reason becomes ASSERTED. The badge counts asserted controls only, and the tool never constructs a framework id it can't source. Honest by construction.
    Can I fake a passing score?
    No. The receipt is Ed25519-signed over a hash of the exact ontology. Edit one action to inflate the grade and verification fails with evidence_hash mismatch. You cannot change the score without breaking the receipt — that's the difference between a log and a receipt.