Does an agent need its own Sigilbase account?

No. Name it in the actor field of its events, so its identity is distinct in the ledger. You can also give it its own API key within your account, scoped to the streams it writes to; the ledger records the actor your code sends, not which key sent it.

Can I log prompts and completions?

You can send them as payload fields. Most customers send hashes and keep the text in their own systems, because retention in Sigilbase is forever and redaction is deliberate, declared and permanent.

What about agents that call other agents?

Each agent is an actor. Carry the run identifier through, and the chain of delegation is visible in the record.

Records of what an AI agent did, held by someone other than you.

An agent acts with borrowed credentials and leaves a log that the company it works for controls. When something goes wrong, that log is the only account of what happened. Sigilbase keeps it where nobody can rewrite it.

Start free See an agent event

Agents are actors

Name each agent as the actor of its events. They then carry actor: agent:<name>, so the record shows which agent acted, and on_behalf_of in the payload shows whose authority it used. A person reviewing the record can separate what the human asked for from what the agent did with it.

The actor is what your integration sends. Sigilbase records it as given and does not tie it to the API key that sent the event. You can still give each agent its own key, scoped to its own streams, to limit what it can write.

Tool calls are events

Record one event per consequential action: a tool call that changes state, a message sent, a payment moved, a record written. Store the arguments as a hash and the result as a short status. Keep the run identifier so a whole episode can be reassembled in order.

POST /api/v1/streams/agent-actions/events

{
  "occurred_at":  "2026-10-06T09:14:02.000000Z",
  "actor":        "agent:refunds-assistant",
  "action":       "tool.called",
  "resource":     "order:118204",
  "payload": {
    "on_behalf_of":    "user:7731",
    "tool":            "issue_refund",
    "arguments_sha256":"b19f…42c0",
    "result":          "refund.created",
    "run_id":          "run_01J9…",
    "model":           "vendor-model-name"
  }
}

What you can then show

Which agent acted, under whose authority, on what, and when we received the record.
The order of actions in a run, with nothing deleted or inserted afterwards.
That the record you hand to a customer, a counterparty or a regulator is the one that existed at the time.

Who holds the pen?

Where a record lives decides what it proves. The same audit trail means three different things depending on who holds it. Only one custody arrangement takes the pen out of the hands of the party being audited.

In the model vendor's logs

Useful to you. Held in the vendor's account, under the vendor's retention, invisible to a regulator or a customer.

The vendor's pen.
In your database

Observability tools show you everything. They cannot show anyone else that you did not change it afterwards.

Your pen.
In Sigilbase

Held by a third party, anchored beyond everyone, verifiable offline by the person who contests the decision.

Nobody's pen.

What this does not do

Sigilbase does not observe the agent. It records what your integration sends. If the agent takes an action your code never reports, there is no event, and the record is incomplete in a way the verifier cannot see. Coverage is your control, and the honest answer to "did you log everything" is "here is the code that logs".

What this proves, and what it does not

Sigilbase proves that a record has not been modified, deleted or reordered since we received it, when we received it, and which identity sent it. Any lawful redaction is declared, never silent.

It does not prove that a model produced the output in the record, or ran at all. It does not prove a decision was accurate, fair or lawful. It does not prove that everything which happened was recorded; coverage is the sender's control. It does not prove the sender's claimed time, only ours. And it says nothing about the period before the sender started.

Sigilbase is the evidence layer. The conclusion belongs to the person examining the evidence.

Questions about agent records

Does an agent need its own Sigilbase account?

No. Name it in the actor field of its events, so its identity is distinct in the ledger. You can also give it its own API key within your account, scoped to the streams it writes to; the ledger records the actor your code sends, not which key sent it.
Can I log prompts and completions?

You can send them as payload fields. Most customers send hashes and keep the text in their own systems, because retention in Sigilbase is forever and redaction is deliberate, declared and permanent.
What about agents that call other agents?

Each agent is an actor. Carry the run identifier through, and the chain of delegation is visible in the record.

Start recording provable history

Chained, sealed, independently verifiable audit logs, from the first event. Free while Sigilbase is in beta.

Start free Read the auditor guide

Questions first? Write to hello@sigilbase.io.

More in this section

AI audit records. Why an AI decision log needs a custodian, and the rules that ask for one.
AI decision logging. One event per decision, what to put in it, and what it proves.
EU AI Act record-keeping, plainly. Articles 12, 19 and 26 in plain words, and where Sigilbase fits.
UK automated decisions. The 2025 Act's safeguards, and the record a contested decision needs.
ISO/IEC 42001 event logs. What control A.6.2.8 asks for and what a certifier samples.
For AI assurance providers. The verifier, auditor grants and how to request evidence.