The next big risk in physical-security AI is not that the system sees too little.
It is that the system is allowed to do too much before anyone has defined the boundary.
Security teams are already comfortable with AI that filters video, groups alerts, searches footage, drafts incident summaries, or flags activity for review. The harder questions begin when the same technology starts recommending an escalation, changing an access decision, prioritizing a dispatch, or initiating part of a response workflow.
Those actions may sit inside the same platform. They do not carry the same risk.
That is why the most useful AI governance question for security leaders is becoming surprisingly simple:
What, exactly, is this system authorized to do?
The label describes a technology category. It does not describe operational authority.
One AI tool may summarize an incident report. Another may recommend that an operator escalate an event. A third may change a credential, open a workflow, notify outside parties, or trigger a physical response.
Treating those systems as equivalent because they all use AI creates two problems.
First, low-consequence tools get buried under controls designed for much riskier applications. Useful automation becomes harder to adopt.
Second, high-consequence tools can slip into live operations under the same broad approval given to a search feature or reporting assistant. That is where convenience quietly becomes authority.
The dividing line is not AI versus non-AI. It is what the system can do after it reaches a conclusion.
Security leaders can make the conversation concrete by placing each use case on an authority ladder:
Each step changes the control requirement.
An inaccurate summary may waste an investigator’s time. A flawed recommendation may send attention in the wrong direction. An incorrect access change or response action can affect a person, disrupt an operation, or create a safety issue.
The more authority the system receives, the more proof the organization should require.
People do not receive access to sensitive systems as anonymous, all-purpose users. AI agents should not either.
NIST’s current work on software and AI-agent identity and authorization points toward a familiar security principle: a system that acts needs a distinct identity, defined permissions, and an auditable record of what it was allowed to do.
That matters in physical security because an AI feature may touch several systems at once. Video, access control, visitor management, incident reporting, mass notification, and dispatch can all converge inside one workflow.
If an agent uses a shared service account with broad privileges, the organization may struggle to answer basic questions after an incident:
If those answers are unavailable, the system has more power than accountability.
Broad permission is easy to configure. It is also difficult to defend.
An agent that can help investigate a forced-door event does not automatically need permission to change credentials. A tool that can draft a notification does not automatically need permission to send it. A system that can recommend a dispatch does not automatically need authority to initiate one.
Security leaders should define permissions around the task, not around the platform.
That means asking:
This is least privilege applied to an operational workflow. It is not an AI-specific invention. It is a proven security discipline adapted to a new kind of actor.
“Human in the loop” sounds reassuring. It can also be meaningless.
If an operator receives too many recommendations, has only seconds to respond, or cannot see why a system reached its conclusion, the approval step may become a reflex. The person is technically present but operationally absent.
Useful human oversight requires enough context, time, authority, and training to challenge the system.
For higher-consequence actions, the operator should be able to see what triggered the recommendation, understand the proposed action, reject or modify it, and know what happens next. The system should make disagreement possible, not merely record a click.
Human judgment matters most at the boundary between interpretation and consequence.
Traditional logs often show that an event occurred. Agentic workflows require a fuller record.
Security teams should be able to reconstruct:
That record supports investigation, tuning, accountability, and trust. It also helps separate model error from configuration error, bad data, excessive permission, or a weak approval process.
Without that chain, the organization may know what happened but not why.
Security operations are built around exceptions. Doors fail. Sensors drift. Data arrives late. People behave in ways a model did not expect.
Any system allowed to act should also have a defined way to stop, reverse, or contain the action.
Before deployment, teams should test questions such as:
Recovery cannot be an improvised response to the first serious failure. It is part of the design.
1. What level of authority does the system have: observe, recommend, decide, or act?
2. What is the consequence if its output is wrong?
3. Does the agent have a distinct identity and narrowly defined permissions?
4. Which actions require meaningful human approval?
5. Can we reconstruct what the system observed, recommended, decided, and did?
6. Can an operator override, contain, or reverse the action quickly?
7. Has the complete workflow been tested under realistic failure conditions?
These questions should appear in procurement, system design, pilot acceptance, change management, and ongoing review. They are not a one-time checklist for launch day.
Physical-security AI is becoming more capable. That does not mean every capability should receive the same authority.
The organizations that use AI well will not be the ones that automate the most. They will be the ones that delegate deliberately.
Give each system a clear identity. Limit its permissions. Define the approval point. Preserve the audit trail. Build the override. Test the recovery path.
Then expand authority only when the controls are ready to expand with it.