PacSpace
Talk to us
Government · How the record holds

Conventional cyber defenses guard where records live, not what records say.

An adversary who gets inside a government system would rewrite its logs on purpose: hide what happened, or manufacture what never happened.

Where records live

The perimeter and the record do different jobs.

An archive behind a secure perimeter can still be rewritten by whoever holds the keys, and nobody outside can check it without asking. A committed record cannot be rewritten: the attempt fails the check, and the check catches the change.

It is an integrity control on the record itself, and it composes with everything you already run; the perimeter protects where the record lives, we make what the record says checkable.

The operator still chooses what to write, the same limit every log has. What it gives up is changing the record afterward. If writing stops, the gap shows: the records on either side put a start and an end on it.

An intruder inside the system

What an intruder can and can't do.

Change or remove an entry
Not one already committed. A changed copy fails the check, and the record shows where.
Stop the writing
The gap shows. The records on either side put a start and an end on it.
Steal the write credentials
They could add entries of their own from then on, and those entries would carry their times. They could not change or remove the entries already committed.

So keep the write credentials where the agent, and anyone who reaches it, can't get to them, and treat an entry nobody expected as a signal.

What leaves PacSpace

What PacSpace holds, and what leaves it.

PacSpace holds what the operator writes in an entry, to run the service, encrypted in storage, and uses it for nothing else.

What leaves PacSpace is each entry's seal, committed to the proof layer, infrastructure no party controls, PacSpace included. A seal shows that an entry was made and when, and nothing about what it says. A good habit is to write references and leave personal data out.

A reader sees only what the operator reveals: every seal, in order, and a count of what was withheld, with each revealed field checked against its seal. Checking never shows a field the operator kept back.

Checking without us

The check runs on the reader's own machine.

The operator can hand over a record's history file, and our open-source checker reads what was committed directly and compares it with the file on the reader's own machine.

Neither PacSpace nor the operator is involved while that check runs. If PacSpace went away, the seals would still be there, and the history file would still check.

In a technical review, we walk a program's engineers through exactly what the design trusts.

What PacSpace won't do

PacSpace records and never decides. What happens next is decided above it.

01

It doesn't detect, attribute or stop anything.

The record shows that a change occurred and where. Who did it, why, and what follows belong to the operator, the perimeter and the oversight body.

02

It builds no view across programs, people or tenants.

A government checks its own records and nobody else's, and no customer gains sight of another's records through PacSpace.

03

It never decides whether an action was right.

We do not judge, rank, meter, or score. The people who rely on the record read it, check it, and decide.

04

It is not an identity system.

Who or what acted is whatever the operator writes. Proving identity stays with the program's own identity systems.

The risk runs on a spectrum. In commerce, the record settles good-faith disagreements. At the other end, in national security, the same record holds against an adversary working to change it. The discipline is identical. What changes is why the record moves.

Talk to us

Bring the case you think breaks it.

We would rather be evaluated by use than by description. Talk to us and we'll put you in a live environment: commit a record, do your best to change it, then check it yourself, with us out of the loop. The change shows.

The record must exist.