Greymatter records every request, AI agent action, and tool call with the person behind it. Investigations take one search, not weeks of piecing logs together.
The 7 days to 2026-11-09 14:00 UTC, one bar per UTC hour · click an hour to show its requests
Mon
6,214
Tue
7,032
Wed
6,881
Thu
7,456
Fri
5,903
Sat
1,124
Sun
3,688
00:00
23:00
TRAIL
SERVICE
–
1
greymatter-edge
ztfabric
2
greymatter-dashboard
ztfabric
3
greymatter-api
ztfabric
4
greymatter-docs
ztfabric
–
1
jupyterhub-edge
jupyterhub
–
2
jupyterhub-proxy
jupyterhub
3
jupyterhub-jupyter-p●●●●●
jupyterhub
4
jupyterhub-hub
jupyterhub
Each service sits under the service that called it most. A name under a service that came only from a header an application set names this person.
Actions: the requests this person made. Console reads: the reads the Console repeats while its page is open. They carry this person's sign-in, but the person did not ask for them. The server tells them apart from the method, the path and the response code.
REQUESTS AT JUPYTERHUB-JUPYTER-P●●●●●
TIME
ACTION
PATH
WORKLOAD
DECISION
CHAIN
21:38:31
GET
/user/p●●●●●/api/kernelspecs?1794173911688
jupyterhub-jupyter-p●●●●●
Served 200
3 hops →
21:38:30
GET
/user/p●●●●●/api/me?1794173910685
jupyterhub-jupyter-p●●●●●
Served 200
3 hops →
IDENTITY
OIDC
p●●●●●@example.com
4,812
REQUESTS 24H
1,236
ACTIONS 24H
0
BLOCKED
0
DENIED
ACTIVITY · 24H
Not read: how identities are classed, for Nov 2 UTC, Nov 8 22:00–Nov 9 12:00 UTC. A non-human identity may show as a person until it is read.
WHAT IS HAPPENING
4,812 requests to 23 services in 4 namespaces in this window; 12 failed, 0 denied by policy. First seen 2026-11-08 14:02 UTC, last seen 2026-11-09 13:58 UTC.
Event chain · GET /user/p●●●●●/api/kernelspecs?1794173911688
p●●●●●@example.com
One audit record per hop the request passed, in order. Each hop records how the request was carried.
1
jupyterhub-edgeInbound · Listener :10908200 · 19 ms
TLSv1.3
p●●●●●@example.com · source: jwt · header: from
User p●●●●●@example.com, verified at jupyterhub-edge
2
jupyterhub-proxyInbound · Listener :8000200 · 14 ms
The 7 days to 2026-11-09 14:00 UTC, one bar per UTC hour · click an hour to show its requests
Mon
6,214
Tue
7,032
Wed
6,881
Thu
7,456
Fri
5,903
Sat
1,124
Sun
3,688
00:00
23:00
TRAIL
SERVICE
–
1
greymatter-edge
ztfabric
2
greymatter-dashboard
ztfabric
3
greymatter-api
ztfabric
4
greymatter-docs
ztfabric
–
1
jupyterhub-edge
jupyterhub
–
2
jupyterhub-proxy
jupyterhub
3
jupyterhub-jupyter-p●●●●●
jupyterhub
4
jupyterhub-hub
jupyterhub
Each service sits under the service that called it most. A name under a service that came only from a header an application set names this person.
Actions: the requests this person made. Console reads: the reads the Console repeats while its page is open. They carry this person's sign-in, but the person did not ask for them. The server tells them apart from the method, the path and the response code.
REQUESTS AT JUPYTERHUB-JUPYTER-P●●●●●
TIME
ACTION
PATH
WORKLOAD
DECISION
CHAIN
21:38:31
GET
/user/p●●●●●/api/kernelspecs?1794173911688
jupyterhub-jupyter-p●●●●●
Served 200
3 hops →
21:38:30
GET
/user/p●●●●●/api/me?1794173910685
jupyterhub-jupyter-p●●●●●
Served 200
3 hops →
IDENTITY
OIDC
p●●●●●@example.com
4,812
REQUESTS 24H
1,236
ACTIONS 24H
0
BLOCKED
0
DENIED
ACTIVITY · 24H
Not read: how identities are classed, for Nov 2 UTC, Nov 8 22:00–Nov 9 12:00 UTC. A non-human identity may show as a person until it is read.
WHAT IS HAPPENING
4,812 requests to 23 services in 4 namespaces in this window; 12 failed, 0 denied by policy. First seen 2026-11-08 14:02 UTC, last seen 2026-11-09 13:58 UTC.
Event chain · GET /user/p●●●●●/api/kernelspecs?1794173911688
p●●●●●@example.com
One audit record per hop the request passed, in order. Each hop records how the request was carried.
1
jupyterhub-edgeInbound · Listener :10908200 · 19 ms
TLSv1.3
p●●●●●@example.com · source: jwt · header: from
User p●●●●●@example.com, verified at jupyterhub-edge
2
jupyterhub-proxyInbound · Listener :8000200 · 14 ms
Logging traffic tells you a request happened somewhere in your systems. A forensic record tells you who acted, what they did, and what happened as a result.
LLM05 Output Handling: RCE primitive emitted in model
Nov 3 19:26:35
PUT /user/m●●●●●●.r●●●@example.co…
Record ID: ce4999a1-aa9d-48bb-93bc- 26e5227d04be
jupyterhub-jupyter-m●●●●●●-r●●●-ex…
no record of yours at this hop
supplychain
LLM03 Supply Chain: Model loaded in code with remote
IDENTITY
OIDC
m●●●●●●.r●●●@example.com
361
REQUESTS 24H
361
ACTIONS 24H
0
BLOCKED
0
DENIED
ACTIVITY · 24H
Not read: how identities are classed, for Oct 28 UTC. A non-human identity may show as a person until it is read.
WHAT IS HAPPENING
361 requests to 4 services in 1 namespace in this window; 0 failed, 0 denied by policy. First seen 2026-11-03 17:06 UTC, last seen 2026-11-03 19:26 UTC.
Pick a personClick a record IDThe full Guardrails record
One structured event. The human, the agent acting for them, the action, the result, and the time. Written the moment the transaction crosses the platform.
Open the case file
Hand leadership answers, not a stack of files.
Pull up any request and see the person, the action, and the outcome together. Select a field to see how.
A shared login tells you nothing when an incident hits. Greymatter confirms the person at sign-in, and that verified name travels with the request. Greymatter ignores any name a client tries to fake.
Each hop records the service reached and the request made, with credentials scrubbed first. A token becomes a keyed fingerprint that nobody can reverse or replay. Passwords and one-time codes never enter the record.
Follow one session from sign-in to last use, with nothing in the record an attacker could reuse.
Every incident starts with one question: did they get in? Greymatter marks each request allowed, denied, or failed, right beside the rule that decided it.
Most tracing breaks when one app drops a header. Greymatter carries the verified person from hop to hop and joins each hop's record into one chain. A hop links to its caller only when the caller's verified identity proves it, never on an ID a client chose.
Open one request and see every service it reached, with the person on every hop.
TOP PEOPLE BY HOUR
Last 24 hours View all 198 people →
m●●●●●●.r●●●@example.com
361
p●●●●.s●●●@example.com
342
d●●●.o●●●●@example.com
318
k●●●●.m●●●@example.com
296
s●●.o●●●●●@example.com
271
l●●●.f●●●●●●@example.com
254
o●●●.h●●●●●@example.com
233
n●●●.b●●●●●●@example.com
221
a●●●●.k●●●@example.com
209
l●●●●.s●●●●@example.com
196
Call record
Ran tool get_doc_metadata on docs · Nov 2, 7:59:37 PM
THE REQUEST
WHO
p●●●●.s●●●@example.com · verified at an earlier hop, carried by Greymatter
WHERE
greymatter-edge · router listener :10936
WHEN
Nov 2, 7:59:37 PM
ANSWER
200 OK
PROTOCOL
Modern · MCP 2026-07-28
WHO ACTED
AGENT
docs-assistant · AI agent
ON BEHALF OF
p●●●●.s●●●@example.com
Credential fingerprints
Every token is kept as a keyed fingerprint. Raw values are never stored.
p●●●●●@example.com · source: unverified · header: from
User p●●●●●@example.com, verified at jupyterhub-edge
Asserted by spiffe://greymatter.io/ztfabric.ztfabric.jupyterhub-proxy · Connecting service spiffe://greymatter.io/ztfabric.ztfabric.jupyterhub-proxy
3 audited hops
01forensic_event.json
Actor
A shared login tells you nothing when an incident hits. Greymatter confirms the person at sign-in, and that verified name travels with the request. Greymatter ignores any name a client tries to fake.
You know who to call before the damage spreads.
TOP PEOPLE BY HOUR
Last 24 hours
m●●●●●●.r●●●@example.com361
p●●●●.s●●●@example.com342
d●●●.o●●●●@example.com318
k●●●●.m●●●@example.com296
s●●.o●●●●●@example.com271
l●●●.f●●●●●●@example.com254
o●●●.h●●●●●@example.com233
02forensic_event.json
On behalf of
When an AI agent goes rogue, the blame lands on whoever owns the login. Every hop of the work records the agent and the person it served.
See who asked and what the agent did with it, so the right one answers for it.
Call record
Ran tool get_doc_metadata on docs · Nov 2, 7:59:37 PM
THE REQUEST
WHO
p●●●●.s●●●@example.com
Verified at an earlier hop, carried by Greymatter
WHERE
greymatter-edge
router listener :10936
WHEN
Nov 2, 7:59:37 PM
ANSWER
200 OK
PROTOCOL
Modern · MCP 2026-07-28
03forensic_event.json
Action
Each hop records the service reached and the request made, with credentials scrubbed first. A token becomes a keyed fingerprint that nobody can reverse or replay. Passwords and one-time codes never enter the record.
Follow one session from sign-in to last use, with nothing in the record an attacker could reuse.
Credential fingerprints
Every token is kept as a keyed fingerprint. Raw values are never stored.
Every incident starts with one question: did they get in? Greymatter marks each request allowed, denied, or failed, right beside the rule that decided it.
Answer on the spot, with proof in hand.
05forensic_event.json
Event chain
Most tracing breaks when one app drops a header. Greymatter carries the verified person from hop to hop and joins each hop's record into one chain. A hop links to its caller only when the caller's verified identity proves it, never on an ID a client chose.
Open one request and see every service it reached, with the person on every hop.
Event chain
GET /user/p●●●●●/api/kernelspecs
p●●●●●@example.com · one record per hop
1
jupyterhub-edge200 · 19 ms
Inbound · Listener :10908
TLSv1.3
p●●●●●@example.com · source: jwt
2
jupyterhub-proxy200 · 14 ms
Inbound · Listener :8000
TLSv1.3 · mTLS✓ Edge link verified
p●●●●●@example.com · source: carried
3
jupyterhub-jupyter-p●●●●●200 · 2 ms
Inbound · Listener :8888
TLSv1.3 · mTLS
p●●●●●@example.com · source: carried
1 / 5 · Swipe for next field
How the trail is built
Every hop writes a record. You get one answer.
Follow one request from a person to a model. Greymatter records each hop where it happens and joins the records into one trail.
Person
p●●●●.s●●●
Signed in with a smart card
Know who is behind every call, even deep in your stack.
record
AI agent
claims-assistant
Acting for p●●●●.s●●●
Trace every agent action back to the person who asked.
record
Service
claims-api
No code changes
Get the full trail with no app changes and no credentials kept on file.
record
Model and tools
claims-llm
Disclosure found in response
See who moved sensitive data, and where it went.
record
One chain per request
The hops of a request, joined into one trail you can open in the Console.
Forensic Audit console
Look up any person, request, or hour. Each reader sees only what their access allows.
Your SIEM and log tools
Send the same records through the Greymatter API. Keep the tools you have.
Change ledger
Prove who changed what. Signed checkpoints let a reader verify it.
62%
Faster audits for one customer.
Evidence builds itself while your team works, not in a last-minute scramble. The record is ready the moment you need it.
Plays well with what you run
Your answers, in the tools you already use.
Read it in the Console or through the Greymatter API. The audit agent also writes every request record to its output, so the log collector you already run can keep it.
Built into the platform, not added on. One installation, one dataset, nothing separate to license or maintain.
Elasticsearch
Kibana
Grafana
Prometheus
Have the answer before anyone asks.
Every month without a forensic record is another incident you cannot fully explain.
Greymatter writes one structured event for every transaction that crosses the platform. The record names who acted, what they did, and what happened. When something goes wrong, the answer is one search away.
A Greymatter forensic event names the actor, the action, and the result in one record. Logs only say that something happened. One shared ID links all hops of the request.
No. Passwords, keys, and tokens never appear in Greymatter logs or records. Greymatter saves each token as a fingerprint, so you can see everywhere the same token was used.
Not in Greymatter tests. A default proxy handled 1,200 requests a second, with 99% of responses under 10 ms and all requests recorded. The record store grows with your traffic.
Elasticsearch
Kibana
Grafana
Prometheus