Attify framework / Public technical note v0.1

Physical Authority Surface (PAS)

A way to describe what an actor can make a physical system observe, trust, decide, command, or do, and how strong the evidence for that claim is.

authority • scale • consequence • evidence

The Physical Authority Surface (PAS) is an Attify framework for describing what physical authority becomes reachable through digital, model, firmware, identity, update, middleware, and controller paths.

Conventional security asks whether an actor can read data, run code, or interrupt a service. PAS adds the deployment question: what can that path cause the system to sense, trust, decide, command, or physically do?

PAS records reachable authority separately from vulnerabilities and risk scores. Two systems with the same vulnerability can expose different authority because their operating context, safeguards, and physical interfaces differ.

Authority tiers: PAS-0 to PAS-5

Assign the highest authority directly supported by the evidence. The tier says what is reachable, not how easy the path is to exploit or how severe its worst imaginable outcome might be.

Tier	Name	Reachable authority	Illustrative context
PAS-0	Observation	Read telemetry, video, logs, or system state.	View a robot's camera feed, status, or operational history.
PAS-1	Configuration	Change settings, thresholds, calibration, or operating modes.	Alter a speed limit, geofence, or safety-related mode.
PAS-2	Input influence	Influence the sensor, model, or policy inputs used for a decision.	Change what a perception or planning component receives.
PAS-3	Model or policy influence	Change the model, weights, policy, planner, prompt, or inference path.	Change which model or policy is loaded through an update path.
PAS-4	Command influence	Issue, modify, replay, or suppress a control command.	Alter a command between an operator, controller, and robot.
PAS-5	Actuation influence	Influence motion, energy, access, dosage, steering, or braking.	Cause or prevent a physical action within the system's operating envelope.

Authority is only one dimension

A useful PAS record keeps authority separate from how far the path reaches, what consequence is supported, and how that conclusion was established.

Scale

Record whether the path affects one component, one system, a deployment, or a fleet. Fleet reach changes the blast radius while the authority tier remains unchanged.

Consequence

Record the supported outcome separately: operational disruption, unsafe behavior, physical damage, or harm. Only evidence of the resulting behavior supports a consequence claim.

Evidence strength

Distinguish documented design, simulation or isolated tests, runtime-observed behavior, and independently observed physical consequence. Each supports a different claim.

Safeguards and recovery

Record which controls must fail or be bypassed, what operators can detect, how the system stops, and whether it can return to a known state.

Companion concepts

Firmware-to-policy attack chain

A low-level software, update, configuration, identity, or middleware path changes what an AI-controlled system sees, loads, trusts, or commands. An attacker can change behavior without attacking the model directly when another layer controls its inputs, policy, or operating envelope.

Adversarial specification gap

A system can pass its declared checks while an attacker-reachable authority path remains outside the specification. Verification asks whether a condition holds; adversarial specification asks whether the condition covers the authority that matters.

How to evaluate a Physical Authority Surface

Apply PAS to a named system and decision rather than a product category in the abstract.

1Name the system, release, deployment, operating mode, and decision boundary.
2Enumerate digital, model, firmware, identity, update, middleware, controller, and physical paths.
3Assign the highest directly supported authority tier to each path.
4Record scale, consequence, safeguards, recoverability, and evidence strength separately.
5Trace firmware-to-policy paths and checks that omit reachable authority.
6State what is observed, inferred, hypothesized, and still missing before making a decision.

Scope a deployment review Apply PAS with the deployment checklist →

Citation and public use

Suggested citation: Gupta, Aditya. “Physical Authority Surface: A Framework for AI Systems That Act in the World.” Attify, v0.1, 2026.

Public PAS material should describe authority classes, trust boundaries, evidence, and consequences without publishing exploit strings, credentials, payloads, firmware modification steps, or procedures for unauthorized physical control.

PAS supports security reasoning and deployment decisions. It is not a certification, safety approval, or claim that every path in a system has been tested.