How AI Is Rewriting the Economics of Physical Security
Key Highlights
- AI agents are reshaping the economics of physical security integration and challenging traditional business models.
- Open APIs and interoperable platforms are weakening proprietary vendor lock-in.
- As integration costs decline, integrators can shift their focus toward managed services, governance and accountability.
- Security buyers must evaluate what AI agents can do with their systems — and who is responsible when something goes wrong.
We’ve been fighting about open versus closed in this industry forever, and most of that fight has been a morality play. Open is virtuous, closed is greedy, everybody pick a team. It was never really about virtue. It’s about who keeps the money when two systems can talk to each other without a custom integration project in the middle — the manufacturer, the integrator, or the people who own and operate the building.
Software answered this a long time ago, and in April it answered again, louder. Salesforce announced Headless 360, making every capability on its platform accessible through an API call, MCP tool or CLI command. AI agents can also operate the platform without using a browser or requiring a human to log in. Co-founder Parker Harris asked, out loud, why you would ever log into Salesforce again. The company that more or less defined the modern software UI now treats the UI as the part you can skip. That should rattle anyone still selling a closed box.
And we sold a lot of closed boxes. Proprietary readers, proprietary credentials, a professional-services line item every time you wanted two things to talk. The lock-in held because getting out was slow and expensive, so most people never tried. AI is quietly removing the slow-and-expensive part, and the whole arrangement tips over once it’s gone.
Where the money is
A closed product makes its money by keeping you stuck. The reader only speaks to the panel, the credential only works on the platform, and anything the vendor didn’t anticipate costs you a check and a few months of waiting. In that model the friction is doing exactly what it was built to do, which is make leaving hard and expensive.
A platform makes money the other way, by being the thing other people build on. Every integration, every credential type, every system that plugs in makes the next one easier and raises the cost of ever walking away — not because you’re trapped, but because you’d be giving up an ecosystem you’ve come to depend on. A closed system pulls value out of you. An open one gets more valuable the longer everyone keeps building on it.
You see it most clearly in the credential. The interesting move isn’t issuing a card; it’s issuing, revoking, and auditing a credential in code, the way Stripe turned accepting a payment into a few lines a developer drops into anything. No app to deploy, no controller to swap, nothing to babysit. A credential stops being something you issue and becomes something you call.
The agents change the math
Access control has never run on its own. It swaps data with the HR system when someone joins or leaves, pulls identity from whatever directory the company runs, ties into video and visitor management, and reaches the controls behind the elevators and the lights. Those are all APIs, and most of them have been in place for years. None of it waited for AI agents.
What they change is the cost. Until recently, every one of those hand-offs was its own project: a developer, a budget, a couple of months. That expense is what kept lock-in standing, and an agent erases it.
An agent is software that doesn’t just answer you but goes and does things, and it lives on APIs. It doesn’t watch your demo or read your one-pager; it calls interfaces, and it will operate whatever surfaces a system leaves open. So the value of being open just got repriced. A platform an agent can drive is suddenly worth far more, and a closed one becomes a wall the agent routes around.
The expensive, miserable integration work that propped up lock-in for 30 years is collapsing toward nothing. An integrator can wire a working agent into a modern access platform in an afternoon and run most of a test cycle without opening the console once. A year ago that was a six-week statement of work. That shrinking invoice is the integrator’s, and it’s the first thing this shift comes for.
The economics reach the price book, too. Per-seat licensing stops meaning much when the seat is software doing the work of ten people, and pricing is already drifting toward consumption to match.
So the moat was never the technology, it was the pain. Take the pain out of integration and the old moat is gone. If you sell systems for a living, that reads like a threat: customers doing for themselves what you used to bill for. Sit with it, because it’s the most serious objection to everything here, and the rest of this is about working through it.
The four surfaces
Auston Bunsen, who founded the credential platform AccessGrid, has a good shorthand for the surfaces that matter: CLAMS — CLI, API, MCP, SDKs. They run from the most open-ended way to operate a system to the most defined, which happens to be the order an agent reaches for them.
The following chart illustrates how these interfaces differ in the access and control they provide, with greater governance as you move up the framework and SDKs serving as a supporting development layer.
A CLI, the command line, is the surface we set aside years ago in the name of “security,” and it’s worth a second look. Agents are text creatures, and the command line is their first language. Give an agent a CLI and it can drive your system out of the box, because it already knows how a terminal works. Left wide open it exposes everything the system can do; run inside a locked-down environment, it can be fenced in tightly. The surface itself draws no lines. You do.
The API is the surface with guardrails: defined endpoints, predictable answers, real limits on what you can reach through it. It’s what an agent calls when it needs to do something precisely and at scale. Every serious platform has one now, which is why having one stopped being a selling point.
MCP, Model Context Protocol, is the frontier. It’s an open standard, now run under the Linux Foundation and backed by every major AI platform, that hands an agent a labeled set of tools and states up front what each one does and what it can’t touch. Why it matters is pure economics. In an agentic world the cost of using a system isn’t a license, it’s tokens — the compute an agent spends every time it reads, reasons and acts.
A platform an agent has to fight to understand is expensive to operate against; one that hands it a clean, defined toolset is cheap. That gap is tiny per call and enormous at scale, and it decides which platforms agents get pointed at. The same definition that makes MCP cheap to run also makes it governable: the provider decides what’s on the menu. Think of an API as the keys to the building and an MCP server as a visitor badge that opens only certain doors and gets logged at each one.
SDKs are the courtesy layer: kits in the languages people already use, so nobody rebuilds the authentication and the error handling from scratch. They turn an integration that takes a quarter into one that takes a week.
CLAMS is best read as a direction of travel. The bar is moving toward all four faster than vendors keep up, which is why the question to ask isn’t “do you have an API” but “what can an agent actually do with this, and where is it headed.”
And the incumbents are moving. Established panel vendors, not just startups, are shipping natural-language agents that confirm an action before taking it and log every one, and rewriting their APIs to be friendly to agents, not only developers.
Standards are a different promise than control
One caution. An MCP server bolted onto a proprietary, closed data model still traps you; it just traps you in nicer language. Open surfaces only pay off sitting on open standards, where the credential, the reader, the protocol, and now the AI layer speak something other than one vendor’s dialect.
I’ve made a version of this argument about credentials for years: the logo on the badge doesn’t have to match the logo on the wall. It’s true one level up now. The agent you use to run a building shouldn’t have to come from the company that sold you the access system.
Getting systems to talk to each other is one promise. What an agent is allowed to do once they’re talking is a different one, and the standard rarely answers that part — it falls to whoever deploys the thing. Which is why “open” sounds reckless to anyone with their name on a service contract.
But I'm the one on the hook for the SLA
That’s the worry that should be nagging at every provider who sells a service instead of a product: my customers pay me for a result, not a system, and I’m the one who eats it when the result doesn’t show up. If any agent can do anything to the system I’m responsible for, how do I stand behind a number I no longer control?
Right worry, wrong target. The free-for-all isn’t openness, it’s ungoverned openness — a surface that exposes everything with nobody defining the limits. A wide-open CLI does that, and so does a naked API. Which is exactly why a provider selling an outcome doesn’t hand those out without fencing them first.
This is where MCP earns its keep. The provider decides in advance what an agent may do, which doors stay shut however the request is phrased, and every action gets logged. You don’t lose control of the outcome; you’re the one defining it. That’s the badge from earlier, and it’s already shipping.
So the letters read differently from different chairs. From a credential platform, more surfaces is simply more open. From a managed-services chair, you lead with MCP and govern it hard, and you don’t expose a wide-open CLI you’d then have to fence in yourself, because “ungoverned” is the one word you can’t put next to “SLA.” That isn’t a watered-down version of openness. If anything it’s a more deliberate one, and almost nobody is making the case for it.
The people worried about commoditization have it backwards. Managed services gets more valuable here, not less. Once every facilities manager has an agent that can act, the scarce thing isn’t the ability to do something, it’s the willingness to answer for it when the agent gets something wrong at two in the morning.
What the customer is paying for, in the end, is that someone owns the result. The cost of the work falls because the agent does the clicking, but the price of owning the outcome holds. The moat moved: it used to live in how painful leaving was, now it lives in who answers for the result. Integrators run the same play, billing less for wiring and more for judgment.
What you're buying
The buying question has changed shape. You’re not purchasing a system anymore. You’re purchasing a spot in an ecosystem and the answer to two questions instead of one. What can an agent do with this thing? And when it does something, who’s standing behind it? A platform no agent can operate is a dead end. A platform any agent can operate with nobody accountable for the result is a liability. The thing worth paying for lives between those two — open enough to plug into everything, governed enough that someone can still promise you an outcome.
SECURITY BUYER TAKEAWAY
Before You Sign: 2 Questions to Ask
- What can an AI agent do with the system?
Look beyond whether a platform offers an API. Determine what actions AI agents can actually perform and whether the system supports interoperability beyond a single vendor's ecosystem. An open interface alone doesn't eliminate proprietary restrictions. - Who answers for it when something goes wrong?
Establish who controls what AI agents are permitted to do, how their actions are logged and who is accountable for the results. Openness without governance can leave responsibility for outcomes unclear, particularly when service-level commitments are involved.
Which answers the question I opened with. The money stops living where it always did. It isn’t in the hardware anymore, because an agent that can’t run the hardware just routes around it. It isn’t in the integration invoice either, because that’s collapsing toward nothing. It moves to whoever owns the layer that’s open enough to plug into anything and accountable enough to answer for what happens next. The box maker who can’t be driven by an agent loses ground, and so does the integrator whose whole product was the wiring. The margin lands with whoever holds the governed control point. The people who own and operate the building finally get real leverage.
Open at the standard, governed at the action: that’s the combination that survives a service-level agreement. The leverage has swung to whoever is buying, so use it. Before you sign, ask what an agent can do with the system, and ask who answers for it when something goes wrong. Both belong in the room now.
About the Author
Andrew CampagnolaAndrew Campagnola
Director of Product Management, Kastle Systems
Andrew Campagnola is Director of Product Management at Kastle Systems and Chair of the Security Industry Association's Built Environment Advisory Board. His experience spans engineering, sales, operations and product management, with previous roles as an end user, integrator, consultant and manufacturer. He is also founder of Securlore, a security consulting firm, and contributes to industry interoperability initiatives through SIA's Credential Design Working Group and the Connectivity Standards Alliance.