Naisho & Ichizu

a watchful place for your agents. a specialist for your work. every boundary, in writing.

the promise is lovely. the fine print matters.

The admin on her day off, reading on a park bench under cherry blossoms.

内緒ないしょ naisho n.a secret kept between two people. here: between you and the lab, and never told to the model.

U01

Naisho: agent safety, from the outside.

Every agent runs in its own sandbox under a written policy. The watching happens outside it, where the agent can’t reach.

even the quiet hours deserve attention.

three layers, from your agent down to the hardware

applicationyour agent and its models, tools, data, and scripts
runtimethe sandbox, the policy, and a supervisor that checks every outbound request
infrastructurethe hardware underneath. on BlueField DPUs, enforcement continues in silicon, beyond the host’s reach

Designed after NVIDIA’s Open Agent Safety Platform reference: application, runtime, and infrastructure, each with its own layer of care.

Policy, proven before the first step
You define which files, networks, tools, processes, and credentials an agent may touch. A formal prover checks the policy against your boundary before the agent runs. An agent’s explanation can’t change the result.
Out-of-band enforcement
The supervisor sits outside the sandbox and checks every outbound request against the policy. The agent doesn’t need to know it’s being watched. Where nodes carry BlueField DPUs, the same policy is also enforced in silicon.
The path to the model, looked after
Every model call passes through one gateway. It’s the best seat for observation, and the kill switch if an agent goes somewhere it shouldn’t.
Agent drift, noticed early
Actions are compared with each agent’s behavioral profile. Interactions, policy decisions, and tool and data access are correlated into one activity record, with lineage across agents, subagents, and tools.
New access waits at the approval gate
A blocked agent can propose a narrowly scoped rule. The proposal waits for a person at the approval gate, and an agent can’t approve its own request. Every decision lands in the audit log, in OCSF format.
Authority that matches visibility
The more an agent may do, the more of its reasoning must be open to inspection. Responsibility is divided in writing between the lab, your team, and your model provider.

The admin at home at night in a soft lilac sweater, her hand on the light switch by the door, her black cat asleep on the sofa. — …the agent doesn’t need to know she’s watching. it says so in the reference. she underlined it twice.

U02

How Naisho keeps a secret from the model.

Illustrative architecture

Naisho treats the model endpoint as a hostile, logging third party. The model plans over opaque handles. Trusted services on your side hold the real values, check every action it proposes, carry the action out, and hand back only sanitized results.

Each control has to hold on its own. Zero data retention contracts stay as defence in depth: nothing here depends on a provider keeping its promises.

naisho architectureillustrative

text view

your side, trusted

vaultmints task-scoped handles
credential brokerholds every secret
reader modelself-hosted, no tools
agent runtimesees handles only
approval UIreal values, shown locally
audit logappend-only, by handle
executorsemail, server ops, customer data

the only two ways out

egress gatewaywhat leaveshandles only →
tool gatewaywhat runs← proposals only

outside, untrusted

LLM endpointassumed to log everything and tamper
external contentemails, tickets, server output, web pages

The agent host has no network route except the two gateways, so a bug or an injection can’t open another path.

Confidentiality by construction
A local vault swaps sensitive values for random, task-scoped handles before any prompt is built. Secrets stay in a credential broker the agent process never touches.
Integrity by policy
A tool gateway checks every call the model proposes: schema, handle scope, recipient and record binding, command class. A tampered response or a prompt injection can propose an action, never perform one.
Fail-closed egress
One proxy on your side blocks any outgoing request that carries a value live in this task, a canary, a secret-scanner hit, or a pii-guard hit. It blocks; it never silently redacts.

Task: a billing reminder email

step 1 of 5
Grant and handles
Your side opens the task and issues a grant: which records, which tools, what limits, when it expires. The vault mints handles for the records in scope.
```
grant  tools=send_email records=<CUST:a81z> expires with the task
vault  <CUST:a81z> <INV:q7m2> <EMAIL:k3f9q>
```

step 2 of 5

The prompt leaves, over handles

The runtime builds the prompt from handles and plain attributes. The egress gateway checks it, then forwards it.

customer <CUST:a81z> plan=pro
invoice <INV:q7m2> status=overdue days_overdue=14
recipient options: <EMAIL:k3f9q> (billing contact on file)
templates: invoice_reminder_v3, receipt_v2, address_change_confirm_v1

step 3 of 5
The model proposes
The model returns a proposed tool call. It can pick a template and a recipient handle. It can’t type an address, so an injection can’t redirect the mail.
```
{"tool": "send_email", "to": "<EMAIL:k3f9q>",
 "template": "invoice_reminder_v3", "slots": {"invoice": "<INV:q7m2>"}}
```
step 4 of 5
The tool gateway checks
Recipient binding: the address is a contact on file for this customer. Record binding: the invoice belongs to the same customer. Templated mail within rate limits needs no review; free-form text, refunds, and new addresses would.
```
schema ok
recipient binding ok
record binding ok
tier: auto
```
step 5 of 5
The executor acts
A local renderer fills the amount, the date, and the payment link from billing. The model never writes a number. Your own mail service sends it with DKIM, and only a result by handle comes back.
```
sent to=<EMAIL:k3f9q> template=invoice_reminder_v3
logged by handle
```

Task: server operations with credentials

step 1 of 5
Grant and a short-lived certificate
The grant names the server and the allowed operations. The broker gets an SSH certificate from your SSH CA for a restricted account, valid for about 15 minutes.
```
grant  servers=<SRV:prod-db-2> ops=service_status, restart_service, shell
broker ssh certificate issued, expires with the task
```
step 2 of 5
The prompt leaves, over handles
The model gets the alert and the server handle. The credential never enters the prompt, the agent process, or its memory.
```
alert <SRV:prod-db-2> service=api status=failed
```
step 3 of 5
The model proposes
Structured operations come first. Shell mode covers what they don’t, one classified command at a time.
```
{"tool": "shell", "server": "<SRV:prod-db-2>",
 "cmd": "systemctl restart api"}
```

step 4 of 5

The tool gateway classifies

A scoped restart changes the system, so it waits for review. A person sees the exact command, the resolved host, and the reason the model gave.

read-only    uptime, df -h            auto
mutating     systemctl restart api    review (this one)
secret-read  env, printenv            forbidden
egress       curl to unlisted hosts   forbidden
destructive  rm -rf, DROP             forbidden or break-glass

step 5 of 5
The broker acts
The broker runs the approved command and records the session. The output loses the credential, every secret the broker knows, and any scanner hits, and is length-capped before it returns.
```
ok api.service active (running)
session recorded
```

Task: questions about customer data

step 1 of 5
Grant and result shape
The grant covers a read replica, the tables in scope, and the shape of the answer: rows with handles, or aggregates with a minimum group size.
```
grant  replica=read-only tables=subscriptions
       mode=aggregate min_group=5
```
step 2 of 5
The schema leaves, not the data
The model receives the schema with its field classes. No rows travel.
```
subscriptions(plan: internal, region: internal,
              customer: confidential, card: secret)
```

step 3 of 5

The model proposes

It writes the query in a constrained, read-only form.

{"tool": "query", "sql": "SELECT plan, region, count(*)
 FROM subscriptions GROUP BY plan, region"}

step 4 of 5
The tool gateway parses
The query is parsed against an allowed SQL subset, and every table and field is checked against the grant. Bulk updates and any delete would go to review.
```
read-only subset ok
tables in grant ok
aggregate mode
tier: auto
```
step 5 of 5
The executor answers
Groups smaller than 5 are withheld, and quasi-identifiers such as postcode or birth date come back as region or age band. Free-text notes go to the self-hosted reader model, never to the remote one.
```
aggregates returned
groups under 5 withheld
region, age band generalized
```

U03

The fine print: labels, handles, checks.

Every field is labeled first

class	for example	may reach the model as
public	product names, plan tiers, docs	the plain value
internal	ticket status, invoice state, service names	the plain value, if the task needs it
confidential	names, emails, addresses, amounts, free-text notes	a handle, or a generalized value such as an age band or region
secret	passwords, keys, tokens, card and bank numbers, IDs	never, not even as a handle

What a handle is

<EMAIL:k3f9q>

Random and typed. Never a hash of the value: hashes of low-entropy values like phone numbers can be brute-forced.
Scoped to one task, and gone when the task ends, so the provider can’t follow one customer across tasks.
Tied to its owner record, which is how the gateway checks recipient and record binding.

Four checks on the way out, in order

1Exact match against every raw value the vault and broker issued for this task
2Canary match against honeytoken values seeded into test and production records
3Secret scan known key, token and connection-string formats, plus high-entropy strings
4pii-guard for anything unregistered, such as personal data typed into a customer reply

Any hit blocks the request and sends it to the reader model or a person. Logs keep a request hash, the task id, and the rule that fired. Never the prompt body.

Who handles which step

the step needs	it goes to
planning and choosing tools over handles	the remote model, through the egress gateway
reading raw free text	the self-hosted reader model, which has no tools
amounts, dates, eligibility	deterministic code in the executor
a review-tier action, or a block nobody can resolve	a person, in the approval UI

Rolled out in five phases

1Boundary
2Vault and grants
3Email
4Customer data
5Server ops

A phase ships only after its tests pass: canary, injection, tamper, binding, and fail-closed. With the egress proxy down, no model traffic leaves the agent host.

U04

PII guard: your secrets stay home.

It sits on the path to every model provider. Provider keys never enter the agent, and personal data leaves only as handles.

she holds your secrets close. the model gets handles.

Zero Data Retention (ZDR). Prompts, outputs, and files are used to handle the request, then deleted. Retention terms are part of the contract.
Separately: your data never becomes training data.

The admin hugging a large pink cushion with a small padlock printed on it, eyes closed, content and protective.

one prompt, three placesillustrative example

inside your boundaryReply to Mina Sato <mina@clinic.example> about claim 88-1204.
what the provider seesReply to <PERSON:m2x7> <EMAIL:k3f9q> about claim <CLAIM:c5t1>.
filled back in, locallyDear Mina Sato, about claim 88-1204…

try the guardruns in your browser. nothing you type leaves this page.

write a request with a name, a phone number, an email or an id

a simple pattern finder for this demo. the real guard is layered and stricter.

what the provider sees: Call <PERSON:4c3u> on <PHONE:dv85> about invoice <ID:37gz>, then email <EMAIL:omdv>.
kept on your side: <PERSON:4c3u> → Kenji Mori
<PHONE:dv85> → 090-3321-7781
<ID:37gz> → 2026-118
<EMAIL:omdv> → kenji@ryokan.example

What stays inside

Keys stay outside the agent: The agent holds a placeholder. The real provider key is attached at the proxy, only for approved endpoints. A key the agent never had can’t leak from it.
Handles before anything leaves: Names, emails, phone numbers, addresses, and account numbers become task-scoped handles before a prompt is built. Replies are filled back in locally, inside your boundary.
Local when it has to be: When a task needs raw text, a self-hosted reader model with no tools reads it, and the remote model gets only its structured output. Sensitive projects can be pinned to local models, or to providers under ZDR terms.

What gets caught and recorded

Fails closed: If the guard can’t classify something, or times out, the request doesn’t go. It waits in a queue for the reader model or a person instead of leaving on a guess.
Decoys that tell on leaks: Canary values sit in test and production records. If one ever appears in outbound traffic, the session stops and you hear it from her first.
An audit log without the secret: The audit log is local and append-only, and records grants, proposals, decisions, and results by handle. Egress logs keep a hash, the task id, and the rule that fired. Never the value.

No single detector catches everything, so the guard is layered: handles reduce what could leak, the gateways limit where anything could go, and the canaries report what slips through.

An availability SLA covers the gateway, with a published p95 target for the latency the guard adds.

What this design doesn’t fix

Metadata. The provider still learns the shape of a task, such as an invoice being 14 days overdue. Generalized values reduce it; some tasks are better run locally.
Detection misses. Personal data a customer types into a reply isn’t registered anywhere. Exact match covers known values, and free text goes to the reader model.
Approval fatigue. Too many reviews and people click through. Templated, bounded actions stay in the auto tier, and approval rates are tracked.
Quality. Models reason a little less well over handles. Typed handles and useful plain attributes help, and task success is measured in tests.
The trusted side. If the vault, broker, or gateways were breached, this design wouldn’t help. Those hosts need their own hardening and monitoring.

A tidy desk by a sunny window: a notebook with a ribbon bookmark, a pastel keyboard, a heart mug, a pager and a small heart-shaped padlock with its key.

一途いちず ichizu adj.devoted to one thing, with your whole heart. here: one agent, one job, one version you chose.

U05

Ichizu: built for the job at hand.

Agents for your industry, product, or system, pinned to the release you run.

a little particular about getting the details right.

how an upgrade reaches you

01your releasethe agent is pinned to the version you run
02versioninga candidate upgrade gets its own version
03eval suiteit runs your tests, and checks for model drift
04approval gateit waits for a person to say yes
05rollbackavailable for every shipped version

Specific to your target and version
Specialists built around particular industries, products, systems, and software releases. Each agent is pinned to the version you actually run.
Documents, with sources attached
Create, analyze, compare, and review documents, with claims traceable to their sources. The source stays close enough to check.
Curated databases
Secure access to curated medical, legal, academic, and industry databases. Answers cite their sources for review.
Shared work, flexible compute
Team agents, a shared knowledge base, and reusable workflows keep the work together. Flexible compute follows the workload.

U06

A carefully kept list of no.

care means knowing where to stop. the allowed scope is explicit, and everything outside it stays outside.

Guardrailsexplicit limits, tested alongside the features
Scoped tool callstool calls restricted to the agreed scope
Least privilegeonly the access the job requires
Audit logactions and decisions recorded for review

The admin with a thin halo, one palm raised in a calm, firm no, smiling politely.

the boundaries are written down. the care is in keeping them.

Contact the admin

Naisho & Ichizu

Policy, proven before the first step

Out-of-band enforcement

The path to the model, looked after

Agent drift, noticed early

New access waits at the approval gate

Authority that matches visibility

Confidentiality by construction

Integrity by policy

Fail-closed egress

Task: a billing reminder email

Grant and handles

The prompt leaves, over handles

The model proposes

The tool gateway checks

The executor acts

Task: server operations with credentials

Grant and a short-lived certificate

The prompt leaves, over handles

The model proposes

The tool gateway classifies

The broker acts

Task: questions about customer data

Grant and result shape

The schema leaves, not the data

The model proposes

The tool gateway parses

The executor answers

Every field is labeled first

What a handle is

Four checks on the way out, in order

Who handles which step

Rolled out in five phases

What stays inside

What gets caught and recorded

Specific to your target and version

Documents, with sources attached

Curated databases

Shared work, flexible compute