Security
A device whose purpose is to type on a computer.
That is the threat model. What follows is published so the design can be assessed on what it does rather than on an assurance.
Threat model
Whoever holds the key can press any key.
Possession of the key confers arbitrary input on the target. Where a shell, a browser or a login prompt is reachable, that is arbitrary code execution: out of band, absent from the target's own logs, unaffected by anything installed on it. No sandbox, no undo, no confirmation.
Two ways it goes wrong: the machine driving it, or the key itself. Where the key sits on the equipment, physical access yields it. Where there is no key at all, physical access is the entire control.
Where the boundary sits
Not in this software. Visibility is bounded by the screen, and AMI cannot distinguish authorized activity from unauthorized. Neither can the target.
That property is also the utility: hardening a build, testing a kiosk, exercising an appliance nothing else can reach. Authorization sits outside the software.
The real gate
Control it the way people are controlled.
There is no privilege model here and there cannot be one. Keystrokes carry the authority of the signed-in account, so every control already applied to human users applies to the agent unchanged. The limit belongs there: an account holding exactly the permissions the task requires.
No new access-control model is introduced here, and none should be trusted in place of the directory, group policy and review process already in force. It is a property of the account, so it holds however the agent is set up.
Two things that follow
Typing is destructive and there is no undo. A misread screen, a wrong coordinate or a confused agent can delete data, alter configuration or approve an irreversible action. Test against restorable systems.
This is design intent, not assurance. Nothing here is audited, certified or tested against a standard. The stated properties are design intent.
What we deploy
No network at all, so physical access is the control.
What we build and deploy is not connected to anything. No address, nothing listening, nothing discoverable, and no route to it from elsewhere. There is nothing in transit to protect, nothing to throttle, and nothing to find.
The control is physical instead. Reaching the equipment confers what a key would confer otherwise: the trust boundary of a console cable, and it should be secured as one.
| Endpoint | The connection | |
|---|---|---|
| What we deploy | the operator's, as for any user | none to secure |
| If you build it connected | the operator's, as for any user | the operator's as well |
Taking away the connection takes away a layer of work. It does not narrow what the agent can do once typing, which was never a function of how it got there.
What it costs
No remote operation. Reaching a target in another building requires something else, and that becomes the exposed surface.
Updates are physical. There is no remote path, by design rather than omission. One fewer way in, one more site visit.
If you build it connected instead
The build you can assemble yourself does use a network, and it carries obligations the deployed product does not. Traffic is not protected in transit, and there is no lockout or throttle, so the key is the whole of the access control.
Run it somewhere you trust, change the default credentials it came with, let as little as possible reach it, and keep it current. See Running it yourself.
What is built in
The controls that are there.
What it does not do
The controls that are the operator's job.
Credentials
The password never has to cross the keyboard, and neither does the card.
A human-managed password vault is supported and is the preferred pattern. The vault stays on the target under the operator's unlock and policy and fills the field directly, so the credential never becomes keystrokes: not in a command, not on the way there, not in the agent's context, and not in anything derived from it. The human unlocks the vault, it fills the page it recognizes, and the agent presses the login control.
Phishing resistance also leaves the agent's judgment. A vault fills only on the site the entry was stored for, so a look-alike page stays empty and there is nothing to submit. Screen content cannot argue with that. Passkeys and smart cards are stronger still: no typeable string exists.
What it does not buy
Disclosure control, not authority. An agent that cannot read the password still operates inside the session the fill opened. Scope the account to the task.
The same holds where the fill is a payment method rather than a password. Not seeing the number is not the same as not being able to spend, so the ceiling on the card, and wherever the operator draws the approval line, are the controls that matter. See Examples.
Browser-scoped. Setup screens, installers, login screens and desktop applications have no vault to fill them, and there a credential is typed like any other input.
Where the record lives
Auditable from both ends, and neither end is a keylogger.
The target retains its own record. Nothing is installed, so its logging surface is unchanged: it sees a keyboard and a mouse and records them with the tooling it already has. Nothing new to take on trust, and unplugging it ends the access unilaterally.
Agent-side activity is recorded where actions are requested, in the shape we refuse to keep: who acted, what class of action, how many characters, never the characters. Observations are recorded alongside actions, since a log of what an agent did without what it saw cannot establish whether a decision was informed.
The limit of what a device can tell you
Counters attest to what was sent, not to what arrived. A keystroke can be played correctly and lost inside the target with every count reading clean.
The screen is therefore the witness: the stated action is checked against what was displayed, and the verdict is retained rather than the picture. It records without intervening, since an auditor able to halt the machine is a second driver.
Frequently raised
The model's own judgment comes with it. It is a layer, not the boundary.
The driving model retains its training. A request it would refuse elsewhere is refused here, and the refusal precedes any keystroke. Stated plainly, because the opposite is commonly assumed.
It catches a different class than permissions do. Permissions bound what is possible; a model declining to proceed catches what is permitted and still wrong, the larger category in practice. Permissions will not stop an authorized actor destroying the correct machine for the wrong reason. Something that reads the screen and objects sometimes will.
Why it cannot be the only one
A bypassable layer is still worth having, and is not where the boundary belongs. Same category as the look-before-act rule: a guardrail on the agent, not an access control on an attacker. Constrain the account as though it were absent.
The one people miss
A screen is untrusted input.
Text on a screen can carry instructions, and an agent reading that screen may act on them. A crafted filename, a web page, an error dialog or a message preview is an input channel into whatever is driving the keyboard.
Neither hypothetical nor specific to AMI: it follows from pointing a language model at arbitrary pixels while granting it input, and computer-use products carry it through more channels still. Scope what the agent can reach, keep the account as small as the task allows, and do not direct it at content that would not be executed by hand.
One-way by construction
Watching and acting are kept apart: what it sees comes in, what it does goes out, and nothing travels back the other way. Chosen for speed, and correct for a second reason: the acting side should not sense and the sensing side should not act.
Structurally different
It is not a thing that types blind.
Something that types blind depends on nobody watching. AMI is closed loop: anything that moves or types refuses to run unless it has actually looked at the screen within the last minute. Releasing a stuck key is exempt.
The rule sits with the agent, and a key holder can go around it. What it provides is that an agent cannot act on an assumption about a screen it has not seen: a correctness property first, a safety property second.
Reporting something
Use private vulnerability reporting on the agentkvm repository rather than a public issue. In scope: driving the target without the key, disclosure of the key, and defects in the way access is checked, the look-before-act rule or the stuck-key watchdog.
Out of scope by design: this types on the target, so anyone holding the key can do whatever the logged-in account can do.