- Built to no shared standard, quality is whatever the model defaulted to
- Data classification unknown; secrets and PII leak through prompts
- Spend lands on a mystery bill, attributable to no one
- No audit trail, no owner, no kill switch
- Can’t be handed to a colleague without becoming their liability
- Quietly outside IT policy, until it isn’t
Where your agents go
to build with AI.
Asgard is the open-source control plane for AI development inside a company. Point an agent at it and it reads your standards, registers its project, provisions real infrastructure, and accounts for every dollar, from the first prompt to wide production. Not a gateway. A governed front door, where every capability is an MCP tool.
docker run asgard # the agent connects to Asgard's MCP control plane → get_standards read company standards before writing a line ✓ STANDARDS.md, SECURITY.md, WORKFLOW.md (v14) → register_project { name: "Fraud Detection", owner, manager, group, class: poc } ✓ gate passed · minted proj-2026-0042 → gateway_credential { project: "proj-2026-0042" } ✓ virtual key issued · budget $100 · models scoped to class → request_resource { type: "s3-bucket", name: "training-data" } ✓ auto-approved · tagged project=proj-2026-0042 → cost_report { by: "group" } platform $41.20 research $12.80 → every $ attributed
Your teams are already building with agents. To whose standard?
In every department, people are pointing AI agents at real problems and shipping software that fills a void, faster than any roadmap can. It happens with or without IT. The danger isn’t the experimentation; it’s that the output is ungoverned, unattributed, and impossible to share safely. Asgard turns shadow AI into governed AI, without killing the momentum that made it valuable.
- Reads your standards before it writes a line
- Classified and policy-checked on every model call
- Every dollar attributed to a project, owner and group
- Full audit trail and a kill switch across the fleet
- Discoverable in the catalog, safe to share and reuse
- Inside IT policy by construction, not by memo
One loop, from first prompt to production.
The headline workflow, designed agents-first. Every move below is an MCP tool, not a UI button. Asgard serves the guidance and mints the credentials; the agent does the work.
- 01
Read the standards
Point a new effort’s agent at the seed repo. It reads your company’s standards, security rules, and workflow over MCP, the authoritative, versioned copy, not a stale snapshot.
get_standards - 02 the gate
Register the project
The mandatory gate. Nothing provisions or spends until a project is registered and active. Registration mints a stable proj-YYYY-NNNN id and records owner, manager, group and classification.
register_project - 03
Provision through the orchestrator
Registration unlocks gateway keys and real services. Cheap, reversible resources auto-provision; high blast-radius ones route for approval. Every resource is tagged with the project.
request_resource - 04
Attribute every dollar
Model spend and infrastructure spend both carry owner / manager / group / classification on every row, so cost rolls up by any dimension with a single query, all the way to wide production use.
cost_report
Six load-bearing parts. One static binary.
The governance spine (catalog, gate, gateway, policy, cost and knowledge) exposed over CLI, MCP, REST + GraphQL and an embedded UI. SQLite by default, Postgres when you scale.
Manifest-driven catalog
Everything an agent can provision is one YAML per service. Adding a service is dropping a manifest plus a Terraform module, no recompile. The terraform connector is the universal path to any cloud.
The registry gate
No keys, no provisioning, no spend until a project is registered. Classification tiers, evidence-gated promotion, and review-date sweeps run the whole lifecycle from POC to wide production.
Governed model gateway
Every model call routes through it: per-project virtual keys, budgets, model allowlists per data class, PII / secret / prompt-injection guardrails, a kill switch, and full audit.
One policy engine
A single Cedar engine queried by the gateway, catalog, workflow and runtime: can this principal do this, against this data class, with this model, and does it need approval, from whom?
Cost attribution
Model and infra spend denormalize the same dimensions, so attribution is a plain query. Daily rollups, month-to-date deltas, an EOM forecast, an org cost tree and a governed cost Q&A.
Knowledge platform
Normative standards, advisory guidance and composable recipes, versioned with an edit trail and per-version diff, full-text search and moderation. Served to humans in the UI and to agents over MCP.
Every capability is an
MCP tool, not just a button.
Most platforms bolt an API onto a human UI. Asgard is built the other way around: the control plane is the agent interface. Discover services, register projects, fetch credentials, read standards, request resources, all as tools an agent can call, with the same authority a human gets in the dashboard.
list_standardsget_standardsregister_projectcatalog_searchcatalog_getgateway_credentialrequest_resourcerequest_promotioncost_report + more {
"mcpServers": {
"asgard": {
"type": "http",
"url": "https://asgard.your-co.com/mcp",
"headers": {
"Authorization": "Bearer asg_pat_…"
}
}
}
} Works with Claude Code, Cursor and Codex. Authenticate with a personal access token, which acts across every project you own or manage, or a per-project key.
Every dollar lands on a project, owner and group.
Model spend and infrastructure spend denormalize the same dimensions, so the org cost tree, month-to-date deltas and end-of-month forecast are a single query, no tagging cleanup, no reconciliation spreadsheet.
Rendered from Asgard’s own UI tokens. The same view ships in the embedded dashboard.
id: s3-bucket category: storage classification_min: poc auto_approvable: true required_fields: [name] provisioner: connector: terraform config: { module: aws/s3-bucket } cost: source: { type: aws-cost-explorer } secret_outputs: [bucket_arn]
Drop this file in. No recompile. The agent can provision it on the next call.
A new service is a file,
not a code change.
Everything an agent can provision is one YAML plus a Terraform module. The manifest declares how it’s provisioned and how its cost is attributed, so the catalog grows without touching the binary.
- Any cloud, any service. The terraform connector is the universal path. AWS, Databricks, Auth0, same manifest, same cost plumbing.
- Any model backend. OpenAI & Anthropic built in. LiteLLM, Databricks Model Serving, vLLM, each an enableable plugin, never core code.
- Cost reads itself. The manifest also declares how the service’s cost is attributed, so spend flows into the same rollup automatically.
The whole spine is open source.
The governance core is Apache 2.0, free to self-host, forever. Enterprise features sit behind clean trait seams in the same binary, so there’s no fork and no second product to run.
The entire governance spine. Self-host the single binary, forever, for free.
- Manifest-driven service catalog + Terraform connector
- Registry gate, classification tiers & lifecycle
- Model gateway, OpenAI & Anthropic built in, any OpenAI-compatible backend as a plugin
- Cedar policy engine & full audit trail
- Cost attribution, rollups, org tree & forecast
- Knowledge platform: standards, guidance, recipes
- MCP control plane (stdio + remote) + CLI + REST/GraphQL + embedded UI
- Basic OIDC sign-in
- SQLite by default, Postgres opt-in
For regulated, multi-team rollouts. Sits behind clean trait seams in the same binary.
- Advanced identity, SAML & SCIM provisioning, beyond basic OIDC
- High availability, multi-instance, coordinated deployment
- SIEM / audit streaming
- Multi-tenant isolation
- Priority support & SLAs
Enterprise licensing isn’t generally available yet. Contact us to register interest.
One binary. Zero external services to start.
The SQLite path needs nothing else running. Boot it, connect an agent, and you’re governing AI development. Move to Postgres and stateless replicas only when you outgrow a single node.
# 1 · run it, SQLite, no external services $ docker run -p 8080:8080 asgard serve # 2 · register the project (the gate) $ asgard project register \ --name "Fraud Detection" --owner you@corp.example \ --manager lead@corp.example --group platform \ --classification poc --budget-usd 100 → minted proj-2026-0042 # 3 · point your agent at the MCP front door $ open http://localhost:8080 # Getting Started → copy MCP snippet
The short answers.
What about the agent work already happening on my teams?
That’s exactly the point. Shadow agentic AI development, people quietly building real tools with agents, is already underway in most companies. Asgard doesn’t stop it; it gives it a front door, so the same work reads your standards, registers, gets scoped credentials, and shows up attributed and auditable instead of on a mystery bill.
Isn’t this just an LLM gateway?
No. The gateway is one component. Asgard is the front door you point agents at for the whole journey, reading standards, registering the project, provisioning real infrastructure, and attributing cost, from the first prompt all the way to wide production use across the company.
How do agents use it?
Agents-first by design. Every capability is an MCP tool, not just a UI button. Connect Claude Code, Cursor, or Codex to the remote MCP server at /mcp with a personal access token or a per-project key.
How is it deployed?
One static Rust binary with an embedded UI. docker run asgard and you’re productive in an afternoon. SQLite needs zero external services; switch the database URL to Postgres and add stateless replicas to scale out. Kubernetes is supported, never required.
How do we add our own services?
Drop a service.yaml manifest and a Terraform module, no recompile. The manifest declares how the service is provisioned and how its cost is attributed. Non-AWS providers use the exact same path.
Govern AI development
from prompt to production.
Open source, agents-first, one static binary. Stand it up today; talk to us when you’re ready for enterprise identity and high availability.