Skip to content
Modules

Lyra — policy as code

One capability-brokered, information-flow-aware policy language governs which tools, models, data, and egress every agent may touch — authored once, enforced at the endpoint.

Lyra is the policy engine. One language and one signed audit log govern what every agent may do: which tools and MCP servers it may call, which models it may reach, which data it may read, and where it may send bytes. Policy is authored once and enforced deterministically at the endpoint by Beacon — no cloud round-trip on the decision path. It brings policy-as-code to agent capabilities: which tools and models an agent may use, which data it may read, and where it may send bytes.

Capability brokering

Lyra is deny-by-default. An agent holds no ambient authority; it holds capabilities that a policy explicitly grants. A capability names a tool or resource and the conditions under which it may be used — role, tenant, data classification, and information flow. This is how Alyria addresses OWASP ASI02 (tool misuse) and ASI03 (identity and privilege): there is nothing to escalate to.

package alyria.lyra

# Default deny — nothing runs without a brokered capability.
default allow = false

# Grant a tool only when the role holds the capability and the
# request carries no data above the tool's clearance.
allow {
  cap := capability.granted[input.mcp.tool]
  input.identity.role == cap.role
  input.data.classification <= cap.max_classification
}

# Explicit deny with an ASI tag — surfaces in the audit chain.
deny[msg] {
  input.mcp.tool == "shell.exec"
  not capability.granted["shell.exec"]
  msg := "shell.exec is not brokered for this identity (ASI05)"
}

Information-flow awareness

Lyra tracks the classification of data as it moves through an agent's context. A policy can allow a tool in general but deny a specific call because the request would carry secret-tier data to a lower-tier egress. This closes the gap that per-call allow-lists leave open, and it is enforced at the same point the data actually flows — inside Beacon's local policy service.

One audit chain

Every allow and deny is signed and streamed to Spectra, producing a single audit chain. That chain is legible to the compliance buyer — mapped to NIST AI RMF and ISO/IEC 42001 — and stronger for the adversarial one, because it records not just what was blocked but the capability and flow that justified each decision.

# Illustrative — validate, test, and roll out a policy
beacon policy test  --input ./samples/mcp-call.json
beacon policy apply ./capabilities.rego

See Umbra for how secret leases plug into a Lyra grant.

← Back to docs