Trust is earned, not asserted: introducing Sunstone Atlas

Add agents. Keep control.

There's a moment every team running AI agents eventually hits. An agent reports that a document is "verified." A sync job says it completed. A multi-step process claims it followed policy. And someone asks the obvious question: says who?

Usually the answer is: says the agent. The system's confidence in its own output is the only evidence on offer. That's fine for a demo. It's not fine when the output is a compliance answer, a published policy, or a decision a business will later have to defend.

Sunstone Atlas is our answer to that problem. It's a governed, MCP-native knowledge and execution substrate for businesses that run agents — infrastructure that sits underneath the agents you already have, so that what they claim is separated, mechanically, from what has actually been proven. The tagline is the whole thesis: add agents, keep control.

It is not a chatbot wrapper and not a no-code agent builder. It's the layer where an agent's proposals become drafts, drafts become human-reviewed publications, publications become Ed25519-signed versions, and an agent's autonomy is a number that goes up with track record and down — instantly — on any deviation.

Atlas is the mechanical layer where agent proposals become drafts, drafts become human-reviewed publications, and publications become signed versions.

A knowledge base that refuses to flatter you

Most knowledge bases treat all content as equally true. Sunstone Atlas Canvas — the live application at the heart of the product — computes an honest status for every unit of content from real data only, never from a hand-typed claim.

Every knowledge unit, skill, and playbook carries a derived status: is it active (a published, signed version exists) or a draft? Is its verification recorded — a named human, a real date — or absent? Is it stale against its own freshness policy? When an agent asks the registry a question, every piece of grounding arrives with a STATUS line baked in, something like:

STATUS: draft (Utkast — forslag, ikke gjeldende praksis) | unlabeled, UNVERIFIED | kilde: developer-reference

The model consuming that grounding is instructed to treat drafts as proposals, to surface "unverified" out loud, and never to cite a developer note as company policy. If two active documents conflict, it must report both — never silently pick one.

The sharpest design decision here is what Canvas doesn't do. The underlying spec says a unit with no provenance block defaults to "verified, confidence 1.0" — absence read as the strongest possible claim. Canvas deliberately refuses that inference and reports unlabeled instead. That wasn't theoretical caution: 334 of 520 knowledge units on our flagship production instance were silently presenting as fully verified until an audit against a customer's own governance rubric caught it. "Verified" is now something a human earns for a document. No importer, no script, no agent can assign it — the shared import gate rejects the attempt with an error message that says exactly that.

Absence of proof is not proof of confidence. Canvas reports the gap instead of quietly filling it in.

Publishing is a ceremony, not a save button

Content moves through a real lifecycle: propose → review → publish → active, and eventually superseded or retired. Publishing creates an append-only version record — which version it supersedes, when, by whom — and the whole payload is Ed25519-signed. Nothing gets silently altered afterward; retiring a document appends a signed marker rather than deleting anything.

Roles have teeth. An author-tier credential — the kind every import script and sync agent runs under — is structurally unable to publish. That's enforced server-side, verified live: an author token calling publish_knowledge gets a hard refusal; the identical call from an admin succeeds. A misbehaving import script can propose bad drafts all day; it cannot make them authoritative. A human is required, by construction.

An author-tier credential — the kind every import script runs under — is structurally unable to complete this step. A human is required, by construction.

Autonomy you graduate into

The same philosophy runs through execution. A published playbook can actually run: each step dispatches to an LLM through an isolated staging gateway, to a deterministic function, or to a human — and every decision lands as a signed, replayable event on a per-run ledger.

But before an agent can perform judgment steps at all, it climbs a clearance ladder: real test runs against staging first, then an explicit human sign-off. And once running, its oversight mode — from block (everything reviewed) through review-after and sampling to monitor — relaxes only as genuine track record accrues, and regresses instantly on any deviation. The agent's charter never silently changes; every graduation and regression is itself an audited event.

This is the inversion that matters. Most guardrail products can only say no — a gateway blocks or caps. Sunstone Atlas is built to let an agent earn yes, provably, with the evidence trail to defend it later.

Most guardrails only know how to say no. An agent's charter never silently changes — every graduation and every regression is itself an audited, replayable event.

Proven in production, not on a slide

Sunstone Atlas isn't a spec. It runs a real, live production deployment today: hundreds of real knowledge units, dozens of skills, real playbooks, real charter-bearing agents, and real principals with real role separation — not a demo seeded with sample data.

The most instructive piece is the Notion sync built for that deployment's own governing documents. A scheduled agent fetches them from Notion and pushes them into Canvas through a registered importer. The design principle is "the agent is the transport, the server is the gate" — Canvas holds no source credentials of its own, and every incoming record passes a validation gate that, among other things, refuses any claimed Notion provenance the run cannot prove it actually fetched. Fabricated provenance isn't discouraged; it's rejected.

Atlas holds no source credentials of its own. Fabricated provenance isn't discouraged by a prompt — it's mathematically rejected at the gate.

The day our honesty gate caught us

Here's the story we think earns more trust than any feature list.

On 23 August, the importer subsystem ran its first live scheduled sync against a real production governance database. It fetched all 37 active documents correctly — and the validation gate rejected every single one. A 100% failure rate, on the mechanism's first real outing.

The cause: for database-scoped importers, the set of "pages this run actually fetched" — the proof the anti-fabrication check validates provenance against — was silently never being passed. So the gate did exactly what it was built to do: faced with provenance claims it couldn't verify, it refused all of them. It failed closed, in the honest direction. The bug was diagnosed from the audit trail, fixed, and deployed to production the same day — along with a write-path fix from the same session that recovered 36 units an older gap had left unreachable.

We built the thing that catches false confidence, and the first thing it caught was our own oversight. We'd rather tell you that story than pretend the system emerged flawless — because a governance product whose own governance has never caught anything real should worry you.

"We built the thing that catches false confidence, and the first thing it caught was our own oversight."

An honest ledger: strengths and limitations

What's genuinely strong today:

• Auditable by construction. Signed, append-only versions and replayable run ledgers aren't an export feature — they're how the system stores state.
• Structural role separation. Author-tier credentials cannot publish, enforced server-side. Script mistakes stay cheap.
• Earned autonomy with instant regression. The trust ladder is live code with a real track record, not a policy document.
• Honest epistemic labeling. The read path tells agents and humans the same truth: draft vs. active, verified vs. unlabeled, stale vs. current — proven necessary on a real production corpus.

What's honestly not there yet:

• No server-held live-fetch automation. Syncing still requires an agent with real source access as the transport. That's a deliberate trust decision, but it means no fully hands-off pull sync today.
• Retired content isn't a distinctly labeled state. Retiring is real and append-only, but a retired unit reads back as a plain draft; nothing on the read path yet distinguishes "deliberately withdrawn" from "never published."
• No per-principal read scoping. Roles gate writes only. Any reader can read everything, including drafts and developer notes.
• Registry answers include drafts by default — labeled, but present unless a caller filters explicitly.
• Tool execution is early. The governed tool-call lane exists, but its transport is young; most real-world side effects still route through humans or deterministic functions.

Where it sits in the landscape

Orchestration frameworks — LangGraph, CrewAI, AutoGen, Semantic Kernel — are good at what they do: wiring agents into workflows. They largely don't attempt governance, and that's a fair division of labor, not a criticism. Sunstone Atlas isn't competing to orchestrate; it's the substrate an orchestrated team runs against.

MCP-ecosystem tooling is growing fast, but the field has a named gap: signing a skill is not the same as verifying it does what it claims. Sunstone Atlas's stance is conformance plus signing plus lifecycle — the signature is the last step, not the whole story.

Enterprise GRC and AI-governance platforms document policies and collect attestations about AI systems. They sit beside the work. Sunstone Atlas sits in it — the governance evidence is a by-product of execution, not a form filled in afterward.

AI gateways and guardrails block, cap, and filter. Necessary, but purely restrictive. The gateway says no; Sunstone Atlas is built so the answer can become yes — provably, incrementally, and reversibly.

If you're evaluating trust infrastructure, apply our own standard to us: don't take this post's word for anything. The whole point of the product is that you shouldn't have to.

---

Sunstone Atlas is built by Sunstone Tech AS. The name comes from the Viking sólarsteinn — the crystal that found the sun's bearing through fog.