Glossary · Governance

Attestation

Making an agent's reachable surface answerable before execution. Audit records what an agent did; attestation lets a reviewer determine what it could ever do, by turning the surface into a declared artifact that can be read, linted and approved in advance.

What is Attestation?

Attestation is the property of a tool surface being inspectable before it runs. It answers a question logging cannot: not what did this agent reach, but what could it reach — if it were confused, manipulated, or simply unlucky.

The distinction matters because the two questions have different tenses. Audit is retrospective: it tells you, perfectly, what happened. Attestation is prospective: it tells you the complete set of operations an agent is able to perform before it performs any of them. A system can have flawless audit logs and still be unable to answer a security reviewer asking what an agent is permitted to touch.

Why the surface has to exist first

Attestation requires a subject — something a reviewer can read. Several common architectures produce none:

  • Retrieval-ranked surfaces are assembled when the agent asks. Before that moment there is no list, only an index that could return many possible lists.
  • Runtime-generated integrations are written from a natural-language description as the task runs. There is no repository, and no version of the surface that predates execution.
  • General-purpose code defeats enumeration by static analysis. Computed URLs, branching and dynamic dispatch mean you cannot read a program and derive the complete set of upstream operations a credential will ever authorise.

In each case the surface is real but ephemeral. It can be logged after the fact; it cannot be approved beforehand, because at approval time it does not yet exist.

What makes a surface attestable

A surface is attestable when four things are declared and reviewable together:

  • The operations the agent is offered, written by an author rather than mirrored from an upstream catalog.
  • The fields each response projects, so undeclared data is absent rather than merely shortened.
  • The upstream calls behind each operation, enumerable without executing anything.
  • The credential, scoped to exactly those calls and nothing beyond them.

Held in a file, these can be linted, diffed and reviewed before a credential is attached. An agent may well have drafted that file — what matters is that a human saw it in between, and that the version which ran is the version that was approved.

Attestation in Naftiko

A capability spec is the artifact. Because it declares its operations, output parameters, upstream sources and identity scope, the complete reachable surface is readable at design time and diffable in version control. Governance rules validate it before deployment rather than detecting violations afterward.

Why it matters

Attestation is the one property that improving models do not deliver. A more capable model takes fewer wrong turns, but it does not make an over-broad credential acceptable, and no amount of intelligence tells a reviewer what an agent is able to reach. That is a property of the boundary, not of the thing reasoning inside it — which is why it usually decides whether an agentic use case is allowed near a production system of record.

Browse all terms