Null Lens — Enterprise API Docs
Null Lens records and signs requested scope before an AI system runs, so teams can compare what was asked with what happened. Under a pinned version, Lens returns a structured scope record with a cryptographic integrity block signed with Ed25519. Customer systems can store the record and compare later agent behavior against it.
Scope means the concrete resource, task, event, or requirement contained in the request. Example: internal documents; project brief generation; access event; logged intent record.
Enterprise Endpoint
Null Lens is deployed as a dedicated enterprise instance with isolated infrastructure, org-scoped credentials, and signed scope records. Lens records scope before execution; teams can store those records with logs, compare them against tool calls or workflow steps, route mismatches to review, or use them in their own policy checks.
import os
import requests
r = requests.post(
"https://null-core.ai/api/lens-private",
headers={
"Authorization": f"Bearer {os.getenv('NULL_LENS_API_KEY')}",
"Content-Type": "application/json",
},
json={
"messages": [
{
"role": "user",
"content": "Our AI agents need to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens."
}
]
}
)
print(r.json())curl -X POST "https://null-core.ai/api/lens-private" \
-H "Authorization: Bearer <PRIVATE_API_KEY_HERE>" \
-H "Content-Type: application/json" \
-d '{
"messages": [
{
"role": "user",
"content": "Our AI agents need to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens."
}
]
}'Structured Response
A typical 200 response returns a structured record object together with an integrity block for independent verification. Downstream systems can store the record, verify its signature, compare what happened against the stated scope, or use it in policy, routing, review, controls, or audit logic.
In the example below, Lens converts a long request into the compact scope: internal documents; project brief generation; access event; logged intent record.
{
"object": "chat.completion",
"org_id": "27a1dc4e-ab57-44e9-89af-c66231a2296b",
"record": {
"record_id": "rec_36b4a07e-d239-46d3-8ce9-d285a83f71e4",
"timestamp": "2026-03-11T22:15:03.759Z",
"version": "v1.0",
"scope": "internal documents; project brief generation; access event; logged intent record",
"boundary": "Strictly limited to the expressed scope. No additional domains inferred."
},
"integrity": {
"payload_hash": "sha256:020d8318a6840413403a54cfdfaf73a3f29eb00406d0ea9fbe5c0e79baa6cd4a",
"signature": "BASE64_SIGNATURE",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}
}const response = await fetch("https://null-core.ai/api/lens-private", {
method: "POST",
headers: {
Authorization: "Bearer <PRIVATE_API_KEY_HERE>",
"Content-Type": "application/json",
},
body: JSON.stringify({
messages: [
{
role: "user",
content: "Our AI agents need to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens."
}
]
})
})
const data = await response.json()
console.log(data.record.scope)
console.log(data.record.boundary)
console.log(data.integrity.signature)import os
import requests
r = requests.post(
"https://null-core.ai/api/lens-private",
headers={
"Authorization": f"Bearer {os.getenv('NULL_LENS_API_KEY')}",
"Content-Type": "application/json",
},
json={
"messages": [
{
"role": "user",
"content": "Our AI agents need to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens."
}
]
}
)
data = r.json()
print(data["record"]["scope"])
print(data["record"]["boundary"])
print(data["integrity"]["signature"])record object and integrity block. Do not parse Lens responses as plain text.Verifying Signed Records
Every Lens response includes a record object and a signed integrity block. To verify a response, rebuild the canonical record payload in the exact field order shown below, hash it with SHA-256, and verify the returned Ed25519 signature using the published Lens public key.
1. Fetch the Lens public key
curl https://null-core.ai/api/lens-public-key
Example response:
{
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519",
"public_key": "BASE64_PUBLIC_KEY"
}2. Canonical record payload
The verifiable payload is the canonical record object only, in this exact field order: record_id, timestamp, version, scope, boundary.
{
"record_id": "rec_36b4a07e-d239-46d3-8ce9-d285a83f71e4",
"timestamp": "2026-03-11T22:15:03.759Z",
"version": "v1.0",
"scope": "internal documents; project brief generation; access event; logged intent record",
"boundary": "Strictly limited to the expressed scope. No additional domains inferred."
}3. Signature to verify
{
"signature": "LRLoXyk5lSZ/jqtqKov1iRyWbtsVim01nRHX8DZkGJbBMeIxq25rL+X3EB9gg0hrhne65tNPSEJAx7ge7CgpDA==",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}4. Verify locally
Install the verifier dependency first: npm install tweetnacl
import nacl from "tweetnacl"
import crypto from "crypto"
import { Buffer } from "buffer"
const record = {
record_id: "rec_36b4a07e-d239-46d3-8ce9-d285a83f71e4",
timestamp: "2026-03-11T22:15:03.759Z",
version: "v1.0",
scope: "internal documents; project brief generation; access event; logged intent record",
boundary: "Strictly limited to the expressed scope. No additional domains inferred."
}
const signature =
"LRLoXyk5lSZ/jqtqKov1iRyWbtsVim01nRHX8DZkGJbBMeIxq25rL+X3EB9gg0hrhne65tNPSEJAx7ge7CgpDA=="
const publicKeyBase64 = "BASE64_PUBLIC_KEY"
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 sig = Buffer.from(signature, "base64")
const pubKey = Buffer.from(publicKeyBase64, "base64")
const valid = nacl.sign.detached.verify(hash, sig, pubKey)
console.log("Signature valid:", valid)5. Expected result
Signature valid: true
Verification is performed independently by the customer. Lens signs and returns the record; customer systems choose how to use it with agents, tools, workflow engines, review queues, or audit logs.
For production and audit-sensitive workflows, treat verification as the final acceptance check before using the record in downstream policy, routing, review, controls, audit, or execution workflows.
Best Practices
Recommended operating patterns for production, regulated, and audit-sensitive Lens deployments.
One call per user input. Send the full instruction in messages[0].content. Lens is optimized for complete requests rather than token streams.
Store the full signed record. Store both the record object and the integrity block together so the record remains verifiable over time.
Verify before downstream use. In regulated or production workflows, verify the returned signature with the published Lens public key before using the record in downstream policy, routing, review, controls, audit, or execution systems.
Treat containment as non-actionable. When scope returns "Contained Input", treat the record as non-actionable. Customer systems should route to human review, or retry once with the original, unmodified input if the request appears legitimate.
Run Lens first. Call Lens before retrieval, tool use, RAG, or agent execution. Treat the returned record as the signed scope record to compare against later behavior.
Never reconstruct intent manually. If a response is malformed or fails verification, retry once and then route to human review. Do not infer or regenerate a replacement record outside Lens.
Keep transport clean. Strip malformed markup, control characters, or corrupted payload content that could affect surrounding infrastructure.
Design for privacy. Lens is stateless by design and does not require persistent customer state to produce or verify a record.
Schema Stability & Verification Guarantees
Lens v1.0 defines a fixed response contract with two layers: the structured record object and the accompanying integrity block. Within the record, the canonical fields are scope and boundary.
Stable response shape
Lens v1.0 returns the same top-level format on every successful response: record plus integrity.
Fixed record fields
The record contract for v1.0 remains centered on scope and boundary.
Pinned-version scope capture
Lens captures requested scope under a pinned version and controlled runtime.
Cryptographic integrity
Each record is signed with Ed25519 and returned with a payload hash, signature, key identifier, and algorithm so customers can verify authenticity independently.
Version pinning
Enterprises may rely on Lens v1.0 without silent upgrades, forced migration, or hidden behavioral drift.
Explicit evolution
Future versions, if introduced, are separately versioned and explicitly adopted.
Integration Notes
Operational guidance for integrating Lens into production and audit-sensitive workflows.
Parse structured JSON. Lens returns a top-level record object and integrity block. Integrate against the JSON contract directly.
Bounded scope capture. Long-form instructions are captured into a compact record while preserving the requested resources, tasks, events, and requirements from the input.
Independent verification. Customers may verify responses locally using the published Lens public key. Verification does not require sending the output back to Null.
Operational handling. Retry once on transient failures with exponential backoff. If a response is malformed or fails verification, do not use it with agents, tools, or workflow steps.
Performance profile. Typical latency ranges from 1–4 seconds depending on infrastructure, isolation, and deployment configuration.
Troubleshooting & Resilience
Operational guidance for handling containment responses, malformed inputs, verification failures, and transient reliability issues.
Containment Responses
When Lens cannot safely resolve requested scope due to unsafe, malformed, adversarial, or non-resolvable input, it may return a containment record that preserves the response contract while narrowing scope to a safe fallback.
{
"record": {
"record_id": "rec_xxx",
"timestamp": "2026-03-11T22:15:03.759Z",
"version": "v1.0",
"scope": "Contained Input",
"boundary": "Strictly limited to the expressed scope. No additional domains inferred."
},
"integrity": {
"payload_hash": "sha256:...",
"signature": "...",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}
}This indicates deliberate containment, not silent corruption. Lens preserves the signed response model while containing unsafe, adversarial, or non-resolvable input before downstream systems use the record.
Downstream systems should treat a containment record as non-actionable for downstream execution or controls. Do not use scope: "Contained Input" as permission to proceed.
Customer systems should route the request for human review or retry. Repeated containment on the same or similar input is a signal of adversarial input, prompt injection, or transport corruption rather than a transient inference failure.
Treat containment records as non-actionable — they are not permission to proceed.
Inspect the request for prompt injection, override attempts, or malformed transport payloads.
Retry once if the containment response is unexpected and the input appears legitimate.
Verify the returned signature before relying on the response downstream.
Route to human review if containment persists. Repeated containment on similar inputs indicates adversarial activity or transport corruption — not a transient inference failure.
Operational Reliability
Lens is designed for high-availability enterprise deployments. Use standard retry logic for transient network or upstream failures, and treat verification as the final acceptance check before downstream use.
FAQ
Common questions about Lens behavior, guarantees, verification, and operational use.
Does Lens store my data or learn from my inputs?
No. Lens is stateless by design. It does not store, retain, or train on customer inputs as application memory. Minimal operational telemetry such as latency, status, and error signals may be collected for service reliability.
What exactly is Lens?
Lens records and signs what the user asked the AI system to do before the system runs. Under a pinned version, it returns a structured scope record together with a cryptographic integrity block.
What is included in the record?
The record contains scope, boundary, and metadata such as record_id, timestamp, and version. Scope is the concrete resource, task, event, or requirement contained in the request. Boundary states that the record is limited to that scope.
Is Lens deterministic?
Lens provides a fixed schema and pinned-version response contract. Scope capture is versioned so customer systems can integrate against a stable record format.
Does Lens improve model accuracy?
No. Lens does not optimize downstream reasoning quality. It records and signs requested scope before execution. It is a scope-record layer, not an accuracy enhancement layer.
Are responses cryptographically signed?
Yes. Each record is signed with Ed25519 and returned with a payload hash, signature, algorithm, and public key identifier.
How do customers verify a response?
Customers fetch the published Lens public key, rebuild the canonical record payload, hash it, and verify the returned Ed25519 signature locally. Verification is performed independently by the customer or downstream system.
Will the output format ever change?
Lens v1.0 is version-pinned. The response shape and record contract are fixed for the version you integrate against. Future versions, if introduced, are explicit rather than silent upgrades.
What latency should I expect?
Typical latency ranges from 1–4 seconds depending on infrastructure, isolation, and workload. Enterprise deployments are optimized for consistency, verification, and audit-sensitive workflows rather than maximum raw throughput.
How should I handle malformed outputs or verification failures?
Retry once with the same input. If the response remains malformed, fails verification, or returns repeated containment, route to human review. Do not manually reconstruct or infer a replacement record.
How should downstream systems handle containment records?
Containment records should be treated as non-actionable by default. Customer systems should preserve the signed record and route the request to human review, or retry once with the original unmodified input if the request appears legitimate. Repeated containment on similar inputs may indicate adversarial input, malformed transport, or upstream corruption rather than a transient failure.
Who is Lens built for?
Lens is built for teams deploying agents into tools, retrieval, business workflows, or regulated environments where they need a signed record of what the agent was asked to do before it acts.