Chapter 03: No standing keys — Doors shouldn’t stay unlocked when no one is in the room.

R92 Corporation
Scroll to move through chapters
03 / 06No standing keys

Doors shouldn’t stay unlocked when no one is in the room.

Access should exist only for the minutes a job takes.

Most security failures happen because permanent keys sit in scripts, servers, and chat threads waiting to be found.

We build around zero standing access: raw secrets stay hidden, access is granted for one session at a time, and when the session ends, the door locks itself.

Chapter link

Chapter 01: The premise — Software used to wait for a person to click a button.

Now software agents do the work alongside us.

When an agent can read, plan, and act across your systems in seconds, bolting it onto old tools is not enough.

The rules for who is acting, what they are allowed to touch, and how you prove what happened have to be built in from the start.

Scroll forward to move through the five ideas that shape everything we build at R92—or press and hold anywhere on the screen to interact with the 3D scene.

Chapter 02: Who is acting — Every action needs a real name behind it.

Agents should never borrow a person’s session or share a static login.

If an agent uses a person’s credentials, you can no longer tell who actually did the work.

A person signs in with hardware they hold. An agent gets its own short-lived pass for a single task—tied to the person who sent it—and that pass expires as soon as the job is done.

Two separate paths—human and agent—entering through the same front door, checked by the same rules, and never confused with one another.

Chapter 03: No standing keys — Doors shouldn’t stay unlocked when no one is in the room.

Access should exist only for the minutes a job takes.

Most security failures happen because permanent keys sit in scripts, servers, and chat threads waiting to be found.

We build around zero standing access: raw secrets stay hidden, access is granted for one session at a time, and when the session ends, the door locks itself.

An agent can ask for access to do a job, but it never sees the underlying secret and can never approve its own request.

Chapter 04: The whole fleet — You cannot look after machines you cannot see.

Watch everything continuously. Change things carefully.

Every laptop, server, and phone is part of one connected system.

Software agents are great at spotting drift and exposure across a whole fleet at once—while any command that actually changes a machine waits for a person to say yes.

Continuous visibility gives your team the full picture in real time without handing over unchecked control of the machines.

Chapter 05: Human approval — Fast at reading. Careful with change.

Agents propose; people decide what matters.

An agent can search knowledge, inspect systems, and prepare a plan in seconds.

The moment an action would change a system or use elevated access, it stops at a clear checkpoint until the right person reviews and approves it.

You get the speed of automation for the research and preparation, while a real person stays in control of every decision that carries risk.

Chapter 06: One shared record — When people and agents share the work, they share the record.

One place for the plan, the work, and the proof.

Work shouldn’t be planned on one board, run silently by scripts in the background, and pieced together later for an audit.

Every step—who asked, which agent acted, who approved it, and what changed—is written into one clear, verifiable trail as the work happens.

No guesswork, no missing steps, and one switch to pause agents whenever you need to.