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 homes, apartment buildings, offices, hotels, and campuses.

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 an API 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 life-safety design — OpenApp orchestrates access; fire code and certified hardware design remain your operator and installer responsibility. See Access control architecture.

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 activity in the dashboard when investigating incidents (API export for audit is evolving; developers should preserve error correlationId values from integrations).

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.