Null Lens™
Know what agents were asked to do before they act.
AI agents now retrieve data, edit code, call tools, and trigger workflows.
Most systems only know what happened after execution. Null Lens creates a signed scope object before the agent acts, so customer tools and policies have something verifiable to check.
Declare scope before action. Give your systems signed evidence to compare, review, or route.
See where the scope object fits.
The failure starts
before the logs.
Logs can show what happened after execution. They do not prove what the agent was supposed to touch before it acted.
Retrieves the wrong data
A user asks for project docs. The agent pulls unrelated customer files because retrieval scope was never declared.
Edits the wrong files
A developer asks for one module change. The agent touches auth, payments, or security code outside the request.
Triggers the wrong workflow
An employee asks for a report. The agent exports data, sends email, or calls APIs beyond the original task.
Null Lens creates the signed scope object before that moment, so customer systems have a concrete record to compare against what happens next.
Lens does not authorize the action or execute the workflow. It gives tools, policies, and workflow gates something verifiable to check.
Next: the scope object Lens returns.
From request to declared scope.
Send the user request to Lens before tools, retrieval, or workflows. Lens returns a signed object describing the requested resource, task, and boundary.
Scope means the concrete resource, task, event, or requirement contained in the request - the part downstream systems can compare against before, during, or after execution.
User request
Our team needs to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens.
Lens output
[Scope]: internal documents; project brief generation; access event; logged intent record
Lens signs this scope with record metadata and an integrity block.
If a later tool call retrieves unrelated documents, generates a different artifact, or skips the logging step, customer systems have a declared scope to compare against.
Scope extraction
Extracts the concrete resources, tasks, events, and requirements from the request.
Signed integrity
Every response includes a payload hash, signature, key identifier, and algorithm for independent verification.
Before execution
Creates the scope record before retrieval, tool use, routing, or downstream agent execution.
Lens creates the scope object first. Customer systems decide what happens next.
Next: why this record matters.
Logs show what happened.
Lens shows what was in scope first.
Prompts, logs, traces, and model outputs can help explain what happened after execution. They do not prove which resource, task, event, or requirement was in scope before the agent ran.
- Teams reconstruct the agent's intent after execution.
- Prompts and logs become the only evidence of what was asked.
- Scope is inferred from behavior, outputs, or outcomes after the fact.
- Security, legal, and engineering debate what was actually in scope.
- No signed pre-execution record exists to compare against.
- Requested resources, tasks, events, and requirements are recorded before downstream execution.
- A signed record is returned in a fixed response contract.
- Integrity can be independently verified by customer systems.
- Security, legal, and engineering reference the same pre-execution record.
- Downstream systems can compare what happened against the signed record.
Lens gives teams a fixed reference point before execution, instead of forcing them to reconstruct the agent's intent later.
Next: where Lens sits in the execution path.
A reference point before
downstream work begins.
Lens is designed to sit before downstream work begins. It creates the signed scope record first, then customer systems can verify it, store it, compare what happened against it, or pass it into downstream workflows.
User Input
A natural-language request enters the system with resources, tasks, events, or requirements that need to be made explicit before downstream work begins.
Null Lens
Your system calls the Lens API. Lens captures the requested resources, tasks, events, and requirements under a pinned version, then returns a signed pre-execution record.
Record + Integrity
Customer systems can verify the signature, store the record, compare what happened against the stated scope, and use it as a stable reference point for policy, routing, review, or audit logic.
Downstream System
Retrieval, tools, agents, workflow engines, or internal gates can use the record as a reference point when deciding what happens next.
What Lens does
- • Captures requested resources, tasks, events, and requirements
- • Produces a signed pre-execution record
- • Signs the returned integrity block
- • Provides a stable reference point for downstream systems
Product boundary
- • Does not grant downstream permission
- • Does not execute tools or business workflows
- • Does not replace customer-side policy systems
Lens creates the record. Your systems decide how to use it.
Next: common integration patterns.
Use the record where
scope needs to be provable.
Lens is intentionally small: it creates the signed scope record. Customer systems decide how that record is used for logging, comparison, review, routing, policy, gating, or audit workflows.
Log-only
Store the signed record alongside execution logs so audit teams can see what was in scope before the system ran.
Compare-only
Compare outputs, tool calls, or workflow steps against the signed scope record after the system runs.
Review-trigger
Route mismatches, expanded scope, or sensitive downstream actions to human review.
Customer-owned gate
Use the signed record inside your own policy engine, workflow gate, or approval layer.
Start with visibility. Add comparison, review, or customer-owned gates where your system needs them.
Next: how customer systems verify the returned record.
Independently verifiable
by customer systems.
Every Lens response includes a signed integrity block. Customer systems can rebuild the canonical record payload, hash it, and verify the returned Ed25519 signature locally using the published Lens public key.
Payload hash
The canonical record payload is hashed before signature verification.
Ed25519 signature
Each response includes a signature, key identifier, and algorithm.
Local verification
Verification happens in your environment. No response needs to be sent back to Null for confirmation.
{
"payload_hash": {
"algorithm": "sha256",
"value": "020d8318...baa6cd4a"
},
"signature": "BASE64_SIGNATURE",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}const canonical = JSON.stringify({
record_id: record.record_id,
timestamp: record.timestamp,
version: record.version,
scope: record.scope,
boundary: record.boundary,
})
const hash = crypto.createHash("sha256")
.update(canonical)
.digest()
const valid = nacl.sign.detached.verify(
hash,
sig,
pubKey
)
console.log("Signature valid:", valid)Signed structure makes the record independently verifiable, not just formatted output.
Lens returns the signed record. Customers choose how to operationalize verification.
Next: deployment model and isolation boundary.
Private isolated deployment
for audit-sensitive environments.
Lens is provisioned through private customer deployments with dedicated runtime boundaries, organization-scoped credentials, and stateless request handling. It is built for environments where teams need a signed record of scope before downstream execution begins.
Dedicated runtime boundary
Lens is provisioned for private customer deployments rather than positioned as a shared public inference product.
Org-scoped access
Access is controlled through organization-scoped credentials and non-discoverable customer endpoints.
Stateless by design
Customer content is processed ephemerally and is not retained as application memory across requests.
Fixed v1.0 contract
Lens returns a stable record + integrity response shape designed for production workflows that need verifiable scope evidence.
What customers get
- • Signed pre-execution records before execution
- • Requested scope captured under a pinned version
- • Clear product boundary
- • A stable reference point for downstream systems
Product boundary
- • Not a shared consumer API
- • Not a downstream execution engine
- • Not a replacement for customer-side policy systems
- • Not a long-term customer content store
Lens establishes the signed scope record first. Customer systems handle downstream decisions and execution.
Private deployment, signed integrity, and stateless handling are part of the operating model — not optional add-ons.
Next: request enterprise deployment.
Put the scope record
before the agent.
Add a signed scope record layer to your AI stack with pinned-version scope capture, local signature verification, and private isolated deployment.
Signed record
Fixed response contract with stated scope, boundary, version, and record metadata.
Local verification
Verify the payload hash and Ed25519 signature inside your own environment.
Private deployment
Dedicated runtime boundaries, org-scoped access, and stateless handling by design.
Lens records and signs scope before execution; customer systems retain responsibility for policy, gating, execution, and audit workflows.
Return to top