Already on AGT? Direct ingest, no SDK swap

Already running Microsoft's Agent Governance Toolkit? Then your agents are producing governed, hash-chained audit events right now — and you can point them at Wytness without installing anything on your runtime. AGT's native output speaks a standard the ingest endpoint accepts directly. Zero Wytness code, one sink configuration.

The whole integration

1import { AuditLogger } from "@microsoft/agent-governance-sdk";
2 
3const audit = new AuditLogger({
4  hmacSecret: process.env.AGT_HMAC_SECRET!,
5});
6 
7// Point AGT's native CloudEvents sink at Wytness ingest.
8audit.addHttpSink({
9  url: "https://api.wytness.ai/ingest",
10  headers: {
11    Authorization: `Bearer ${process.env.WYTNESS_API_KEY}`,
12  },
13  contentType: "application/cloudevents-batch+json",
14});

That's it. AGT batches its audit entries as CloudEvents — an open CNCF standard — and POSTs them to ingest. Your agent code, your policy checks, your chain: all unchanged. The CloudEvents detail is worth pausing on, because it's why this path exists at all: we didn't build a proprietary intake and then grudgingly accept the standard — the ingest endpoint speaks the format AGT already emits, so "integration" reduces to an address and a bearer token. The dashboard fills with your agents, tools, sessions, and events; AGT's hash chain is ingested and surfaced just as it is with the wrapper; and the anomaly engine starts baselining your agents from the first batch.

What you get, and what needs the wrapper

We keep this comparison honest because it decides real architectures. Direct ingest gets you the full dashboard — Events, Agents, Sessions, Registry views — plus AGT chain verification and the anomaly engine over your stream. What it can't provide are the properties that live in the wrapper, because they require your keys at the point of capture: per-event envelope signing with a customer-held key, PII pseudonymisation before egress, and the Evidence Pack guarantees built on both. The Built on AGT page carries the full feature-by-feature table — and the difference is visible in the product itself: events arriving this way are labelled with their capture path, so nobody mistakes them for envelope-signed records. Honest labels over blurred tiers, always.

A migration path, not a fork

The practical pattern we see: start with direct ingest, because it costs one config block and proves the visibility value the same afternoon. The pilot conversation is refreshingly short — no SDK review, no dependency approval, no code freeze; platform teams can try it from configuration they already control. Run it for a week, and the dashboard makes its own case: here are the agents you have, here's what they touched, here's the anomaly the baseline caught.

Then, when non-repudiation or PII sealing becomes a requirement — an auditor asks, a customer contract demands it — swap the sink for the wrapper SDK. The wrapper wraps the same AGT your agents already run, so the second step is a five-minute setup, not a rebuild — and the trail you accumulated in the meantime stays, correctly labelled for what it was. Nothing about starting simple locks you out of the stronger tier later.

Why we support a path that skips our SDK

Because the standard matters more than the funnel. AGT adoption is what makes agent audit trails normal, and teams should be able to try the dashboard against their real traffic without committing their runtime to anything. If the visibility alone is worth it to you, run this way as long as you like — the upgrade will still be five minutes away when you want it. A product built on an open standard should behave like it believes in the standard; accepting the standard's native output, unwrapped, is what that looks like in practice.

Questions about which path fits your setup? Ask us.