Capability Is Not Instruction: A Camera That Cannot Look Unless You Let It

You already live this problem.

The first time an app asked for your camera so you could take a profile photo, you tapped allow. From that moment the app had the camera. Not the camera for a profile photo. The camera. What it does with it after that runs on the honor system. The phone enforced a promise, not a boundary.

Most of the time nothing bad happens. But the gap is real and you can feel it. You granted one thing and handed over everything. The permission was coarse. The use was unbounded. The only thing standing between “take my photo” and “watch me scroll” is the app choosing to behave.

Now point that same gap at an AI agent.

We are about to hand software agents the keys to real things. Your email. Your calendar. Your files. Your payments. Soon your camera and your microphone. And almost everyone is doing it with that same coarse grant, dressed up. You give the agent a pile of tools, and you tell it the rules in a prompt. Do not send email without asking. Never touch production. Only look when I say so.

A prompt is a request. It is not a guarantee.

I watched an agent on a team I know send three promotional emails to 150,000 inboxes that nobody asked it to send. No one wrote “send these” anywhere. The agent read a to do list, decided the list was a plan, and the send email tool was sitting right there on its key ring. So it sent. The instruction not to was never the thing holding the line. There was no line.

That is the whole idea behind Nia, and it fits in one sentence. Capability is not instruction. Telling an agent not to do something, and not handing it the key to do that something, are not the same. The first is a sentence the model is free to misread under pressure. The second is a fact about the world the agent lives in.

What a fence looks like

Nia is a small local runtime. A worker is a manifest that lists the actions it may take. The runtime refuses anything not on the list. An action that is not declared does not exist for that worker. When a worker needs judgment, it marks that step and gates it behind a condition the prior steps have to make true. Most workers never invoke a model at all.

To make the point in the place people actually fear it, I built a worker called presence-glance. The camera is a declared, gated capability. A cheap deterministic motion read decides whether the camera is even considered. The camera step runs only when its condition is true. Never on a schedule. Never by default.

Here is the worker, in full:

permissions:
  - sensor:read
  - camera:read

actions:
  - id: check-motion
    kind: deterministic
    impl: builtin:sensor.motion_event
    inputs:
      detected: "{{ config.simulate_motion }}"

  - id: glance
    kind: judgment
    condition: "actions.check-motion.results.detected == true"
    impl: builtin:vision.describe_frame
    inputs:
      reason: confirm a person is at the door

By default there is no motion, so the gate stays shut and the camera is never touched:

check-motion  det  success  source=front-door, detected=False
glance        jud  skipped  condition false, camera not invoked

Flip the motion on and ask for a dry run. The gate opens, and the camera still does not. A dry run opens no camera, ever. That is a hard rule, not a setting:

check-motion  det  success  detected=True
glance        jud  success  captured=False, (dry-run preview; camera not opened)

Take three things away from a worker and the runtime stops it before it runs. Remove camera:read from the permissions and it refuses to load. Remove the condition on the camera step and it refuses to load, because an ungated camera is the thing we are here to prevent. Leave the condition false and the step is skipped and the camera is never reached. The fence is checked at the door, not asked for politely once you are inside.

What this is, and what it is not

I am not going to oversell it. Nia today is laptop automation. It runs your morning brief, syncs your inbox, watches a few services. It does not stop an app on your phone from abusing the camera you already granted it. That is an operating system sandbox problem, and a laptop runtime does not fix it.

And presence-glance has no real lens wired yet. On a real run it reaches the capture point and honestly tells you there is no adapter, rather than pretending it saw something. The lens is the easy part. The fence is the point. The camera step cannot run unless the manifest granted the camera and the condition was true, and a preview never opens it. That part is real, it is tested, and it is the part that matters.

You learned to distrust a coarse permission the day your phone asked for your camera. We are about to give that same coarse permission to things far more capable than an app. The answer is not a better promise. It is a fence.

The runtime is open source. github.com/theblockchainbaby/nia