* LASN_picture_logo.jpg

 

Locks and Security News: your weekly locks and security industry newsletter
7th October 2026 Issue no. 822

Your industry news - first

 

We strongly recommend viewing Locks and Security News full size in your web browser. Click our masthead above to visit our website version.

 

Search
English French Spanish Italian German Dutch Russian Mandarin


Access control after the human

* Access.jpgBy Evgenii Arsentev, PhD, Chief Executive Officer, AskDocDoc

Last month I read in this newsletter about DigiCert and their AI Trust Manager (a product that gives an AI agent its own identity, an owner and a kill switch). I don't use it, so I can't say if it's good. But I read the piece twice, because a certificate company is now selling something like staff badges for software. And I think your trade will meet this question soon.

I'm not a locksmith and I never fitted a lock in my life. I'm CEO of AskDocDoc (telehealth), and in our company the software development is done by AI agents. Technical support also. In engineering we have only our CTO now. So the accounts in my company are held more and more by programs and not by people, and I had to decide how to control it. In my first piece here I wrote what smart locks inherit from software. Now I want to write about the next part - when the one who holds the credential is not a person.

Who opened the door

In the classic model it's simple. One card is one person. The log shows card number and time, somebody looks who has that card, and you have your answer. If the person leaves, you take the card back.

From what I read in your newsletter, a lot of buildings already have software in the middle. Visitor systems send PINs, contractor apps get access for a morning, building management talks to the door controller through some integration. If one of these is an AI agent (it reads a request and decides by itself what to do), the log will still say "granted". But there is no person to phone and ask.

What I do in my company

I can't tell how your sites are built, so I write only what I do with my agents. It's servers and data for me, not doors, but the problem looks the same to me.

An agent gets access for one task only (not to everything). When task is done, the access is gone. We don't have one big account that "the AI" uses for all jobs. Honestly it was the hardest habit for me, because one account for everything is very convenient (and you don't see what it costs until something goes wrong).

I keep logs that the agent can't edit. They are stored in a place the agent has no access to. If the agent could clean its own record I would not trust that record.

Every automated process in my company has a named person who is responsible for result. Not a team, one person. When something goes wrong I don't accept "the AI did it" from my people, so I don't expect our customers to accept it from me.

And anything which can't be undone needs a human decision. For me it's a change on production. For readers of this newsletter I guess it's anything that physically opens.

Mistakes I see more than attacks

When people talk about agents and security, they usually think about a hacker who takes control of the agent. It can happen. But in my work I worry more about another case - the agent does exactly what it was allowed to do, only in the wrong context.

Let me make an example for doors (I made it up, it didn't happen to me). A contractor has access on Tuesday morning. The job moves to Thursday, somebody edits the ticket, and the agent which manages visitor access just follows the ticket. Nobody hacked anything and every permission was correct. The door still opened at a time nobody wanted.

Agents also sound equally sure when they are right and when they are wrong. I see it every day. So many green "granted" lines in a log don't tell me much. I measured something like this in my own agent tests - a check that never fails didn't prove anything to me, and I wrote about it separately.

Questions I would ask

You know your hardware much better than me, so it's not a checklist. These are the questions I ask in my company before an agent gets access, and I tried to put them in door language.

Can I see in the log if it was a person or a program? If an integration and a human use one account, I can't answer "who" anymore.

Can I give access for one task, and does it end by itself? Something like "Thursday 8 to 12, plant room only" for a contractor.

Where are the records stored, and who can change them? If the same platform gives access and can edit the history, I would ask the vendor how it's protected.

Who is the named owner of each automated rule? I would want a name on paper at installation (not "the vendor" and not "IT").

And what does the agent do when it is not sure? In my company I want it to stop and ask a person.

Why I care about this

At the moment I'm the editor of version 0.1 of the conformance reporting format in the W3C Agent Conformance and Benchmarking Community Group (it's a community group report, not a standard). I'm also contributing a chapter to a forthcoming IGI Global volume, about what an auditor can actually check in an agent run - records, permissions and the named owner. In both places I keep coming back to these same three things.

I think locksmiths and security installers are in a better place than software people were. You already have keyholder lists, audit trails and cards you can take back. So for me the question is only how to keep them when the keyholder is a program.

Evgenii Arsentev, PhD, is Chief Executive Officer of AskDocDoc, a telehealth company where software development and technical support are done by AI agents. He publishes measurement work on how agent systems behave. [email protected], ORCID 0000-0002-9120-7298.

7th October 2026




© Locks and Security News 2026.
Subscribe | Unsubscribe | Hall of Fame | Cookies | Sitemap