OpenApp for operators — what agents can and cannot do

If someone on your team wants to use an AI assistant or automation with your building’s access control, this page explains what that means in practice — without requiring you to write code.

OpenApp is Physical Security as a Service: doors, gates, virtual intercom, guest invites, roles, and audit. About OpenApp and Model by sector describe how it fits private homes, shared apartment buildings, offices (incl. coworking), short-term rentals, hotels, campuses, and locker / parcel flows.

What an “agent” is here

An agent is software that calls OpenApp on someone’s behalf — for example:

• A hotel PMS creating guest invites at check-in
• A custom script opening a parking gate when a courier scans a code
• A coding assistant (Cursor, Claude) wired to OpenApp through the MCP server or an API key
• A voice assistant (Siri, Google Assistant, Alexa, or a ChatGPT Custom GPT) opening one door with a scoped voice key

The dashboard remains the primary place for humans to manage users, portals, and policies. Agents extend what you can automate; they do not replace your responsibility for who gets access.

What agents can do (when properly authorized)

Capability	Example	Who usually approves
Open a door or gate	Parcel delivery integration	Building admin issues API key with entity access
Create or update guest invites	Airbnb / hotel check-in webhook	Integration owner + portal setup
List devices and entities	Monitoring script	Read-only or admin API key
Manage apartment residents (delegation)	Apartment rep adds a roommate	Role policy on the integration
Run provisioning scripts	New wing rollout	Org admin runs scripting once

Technical details for developers: Agents & automation overview.

What agents should not do without explicit policy

• Unlock any door without a known entity id and permission — agents must not guess which relay to fire.
• Share API keys in chat logs, email, or public documents — keys are like master credentials.
• Bypass guest time windows — invites and roles exist for a reason; automation must honor valid_from / valid_to.
• Replace listed life-safety design — OpenApp is ingress-only software. Fire code, independent exit hardware, and certified hardware design remain your operator and installer responsibility. See Life safety and egress.

Your controls as an operator

1. Roles and policies — limit who (human or API key) can open, invite, or administer. Roles getting started.
2. API keys — issue dedicated keys for automation; revoke when vendors change. API keys.
3. Invites — use time bounds and portal scope for guests. Access portals.
4. Audit — review access in the dashboard Activity page, pull the last 30 days via API, export older history, or stream HMAC-signed webhooks to your SIEM. Developers should preserve error correlationId values from integrations. See Query access and audit activity.

Activity page event feed.(click to enlarge)

Close

When to say yes to automation

• Repeatable, documented workflows (guest check-in, recurring vendor access)
• Integrations with systems you already trust (PMS, parcel locker software)
• Read-only monitoring before any unlock automation is enabled

When to involve your integrator or OpenApp support

• New hardware or rip-and-replace decisions
• Multi-building delegation models
• Compliance questions for your jurisdiction

Developers on your team should start with Build an access-control agent and Integrate with existing software.