Security and Trust Model

Identity

Humans, AI agents, and systems are distinct actor kinds. An agent acts on_behalf_of a human, so responsibility stays with a person. Not claimed: a specific authentication mechanism.

Signed events

By default, every event record must be supplied with a signature. The signature validates that the submitter controls the key registered for the actor, and so who owns the change. An event without a valid signature is rejected.

How it works

1. The submitter signs the canonical form of the event with its private key, which never leaves the submitter.
2. The signature travels beside the event in a detached envelope, so the event itself is unchanged: { "event": …, "signature": { "key_id", "algorithm", "canonicalization", "value" } }.
3. Techlog looks up key_id in its public key store, checks that the key is registered to actor.id and is not expired or revoked, and verifies the signature.
4. If any step fails, the event is not recorded, and the caller gets a structured error such as signature_missing, signature_invalid, key_unknown, or key_revoked.

{
  "event": {
    "schema_version": "0.1-draft",
    "idempotency_key": "seed-spring-spin-006",
    "type": "change.implemented",
    "time": "2026-03-11T10:12:00Z",
    "actor": { "kind": "ai_agent", "id": "agent:code-assistant", "on_behalf_of": "user:a.novak" },
    "subject": { "system": "promo-api", "component": "spin-service" },
    "status": "recorded",
    "summary": "Spin endpoint with server-side draw, 20% cap, and one spin per new account",
    "provenance": { "recorded_by": "agent:code-assistant", "method": "agent_submitted" }
  },
  "signature": {
    "key_id": "key:agent:code-assistant:2026-01",
    "algorithm": "ed25519",
    "canonicalization": "jcs",
    "value": "ILLUSTRATIVE-VALUE-not-a-real-signature"
  }
}

The signature value above is a placeholder, not a real signature. Other examples in these docs leave the envelope out for brevity.

Techlog holds public keys only

Techlog has access to a public key store for validation and nothing else. It never holds, generates, or escrows private keys, so it cannot sign on anyone's behalf. Each actor, human, agent, or collector, registers its own public keys. An agent acting on_behalf_of a person signs with its own key, and a person's approval is signed with the person's key.

Proposed defaults

• Algorithm: Ed25519 is proposed. Which other algorithms to allow is an open question.
• Canonicalization: JSON Canonicalization Scheme (JCS), so the same event always yields the same bytes.
• Rotation: a new key is registered before the old one is retired. Retired keys stay in the store so older events can still be verified.
• Revocation: a revoked key stops being accepted for new events. How earlier events signed with it are treated is an open question.

Disabling signatures for testing

Signature checking can be turned off, intended for testing. It is a per-tenant setting that is on by default. When it is off, unsigned events are accepted and are clearly marked as unsigned wherever they are shown, and a policy can still require signed events. It should not be used for production data.

What is not claimed

• A valid signature shows that someone holding the private key produced the event. It does not show that what the event says is true.
• A stolen or leaked private key can sign events until it is revoked.
• No hosted public key store exists, and no particular key-management or certificate scheme is chosen.

Permissions

Least privilege. Reading history, recording events, and approving are separate permissions, and having one does not imply another. Not claimed: a finished permission model.

Tenant isolation

The design goal is that tenants never share event stores or query results. This needs a concrete implementation and independent review. Not claimed: that isolation exists today.

Source provenance

Every event says who recorded it (recorded_by), how (method: collected, agent_submitted, human_entered, or derived), and with what confidence (asserted or corroborated). A reader can weigh a collected event differently from an agent's assertion.

Event integrity

Proposed: append-only storage, content digests on evidence, and hash-chaining as a possible later option.

Techlog does not claim tamper-proof records without a concrete implementation and a threat model.

Retention

Retention is meant to be configurable, with legal-hold considerations. Not claimed: any specific retention period.

Sensitive data

Do not put secrets in events. Evidence is a reference, not a copy of the payload. Redaction is meant to happen at ingestion, before anything is written.

AI-generated content

Content produced by an agent is labeled by actor kind. It is never auto-approved, and a human approval boundary applies before it counts as a decision.

Approval boundaries

Who may approve what is configured per policy. The actor who submitted a change cannot approve it (separation of duties).

Compliance

Techlog can help produce evidence. It does not by itself make an organization compliant.

Threat model status