How to Coordinate Physical Workplace Access with an AI Company Brain

Treat a new hire's physical access as its own workflow, tracked step by step from approval to a verified entry, because an active account and a ticked checklist prove nothing about a badge or a door. We recommend two choices most plans skip. Define the day-one fallback for a badge that is not active as an escorted visitor sign-in with a record, not a favor at the door. And give the starter access profile a review date, so widening it is routine. The company brain shows the safe state, the arrival guidance and the staffed route, and it never holds door rules or security detail.

A tick is not a door that opens

Digital and physical access share an employee identity and prove different things. An active account shows that a digital joiner process ran. It does not show that a badge was printed, that it carries the right facility profile, or that the hire knows where to report. The usual failure is a translation error: HR marks the hire as hired, an identity workflow creates the account, the checklist ticks "access requested", the company brain says the access is ready, and the hire stands at a locked entrance. The tick proved a request. It did not prove authorization, issuance, activation, delivery or entry.

NIST's SP 800-53 catalog separates the same steps in its physical and environmental protection family. Control PE-2 has an organization approve and maintain a list of people with authorized access and issue authorization credentials such as badges. PE-3 has it verify individual authorizations before granting access at entry points and keep physical access audit logs. Each of those is a different state with a different owner, so give each its own value instead of one ready flag. CISA's physical security page lists a Security Planning Workbook for building a foundational security plan, which it describes as designed to scale to most facilities, so put the badge process inside whatever plan your facility has, under a named owner.

The contract

Build a small contract between the HR system, the workplace or physical access system and the company brain. It exposes operational state and copies none of the facility configuration into the knowledge layer. This is an implementation example, not a standard schema:

{
  "employee_id": "worker-1842",
  "start_date": "2026-09-08",
  "workplace_id": "office-north",
  "required_access_profile": "standard-office-hours",
  "authorization_state": "approved",
  "credential_state": "issued",
  "activation_state": "active",
  "delivery_state": "pickup-at-reception",
  "arrival_guide_version": "2026-08-18",
  "fallback_owner": "workplace-service-desk",
  "verified_entry_at": null
}

Keep the employee identifier opaque, use a workplace code and not a description of the location, and give a named service route and no personal contact details. The states are not_requested, pending, approved, issued, active, blocked and verified, and the company brain never collapses approved into active or active into verified. Split the data three ways. The employee view holds the arrival time, public entrance, pickup instructions, current safe status, required identification and support route. The operator view holds request history, approver, credential and activation results, and incident notes. The security view holds profile details, restricted areas, control configuration and investigation evidence. The company brain reads the employee view and nothing else, and it never lists door schedules, alarm procedures, access-group names or who else holds the same access.

Say what each state means in plain words. "Your workplace access is still being reviewed." "Your access is approved, but your badge is not ready." "Your badge exists, but entry is not yet active." "Your badge is active and available at the stated pickup point." If a hold has a security reason, the employee is not owed that reason in chat, so route the question to the responsible team.

The Kipwise employee onboarding solution page positions employee onboarding around assigned knowledge, searchable company information, and progress tracking. Use those capabilities for current guidance and ownership, and keep authorization and credential state in the workplace system that controls them.

Day one without a badge

Plan the failure that no checklist covers: the hire arrives, approval is in, and the badge is not active. Without a defined path, the front desk improvises, and improvisation looks like tailgating, a borrowed badge or a propped door. We recommend writing the fallback into the workflow as an escorted visitor sign-in. The hire signs in at the staffed desk under your existing visitor procedure, is escorted by the manager or a named buddy, and the entry is recorded and expires at the end of the day.

SP 800-53's PE-3 has organizations escort visitors and control their activity in circumstances they define, and PE-8 has them keep visitor access records of names, identification, dates, entry and departure times, purpose and the person visited. Its discussion of PE-2 notes that people holding permanent access credentials are not visitors. NIST does not address new hires, so this is our reading: until the credential is active, a hire is on the visitor side of that line. The fallback leaves a record, ends by itself and gives the desk something sanctioned to do. Have the security owner approve the path and keep restricted areas out of it. The company brain's job is to give the hire the desk's name and a case reference, and to refuse to suggest any other way in.

Least access, with a review date

Keep a small catalog of reviewed workplace profiles, each with an owner, intended population, allowed locations, effective hours, prerequisites and review date. Give the first work period the least access that does the job. A standard office hire may need the main building and an assigned floor, while a laboratory or operations hire may need a separate training or safety approval before a restricted area activates. If the required profile depends on training, licensing, manager approval or local safety confirmation, report that dependency as pending. Never substitute a broader default profile to make the checklist look complete.

We recommend writing the review into the record, with an access_review_due a month or so out when the manager widens the profile or confirms it. SP 800-53's PE-2 has an organization review the access list at a defined frequency and remove people when access is no longer required, and a starter profile is the entry you know will need adjusting, because it was sized for week one. A date turns widening into a routine request, where otherwise the pressure to grant extra doors lands on day one.

Microsoft's lifecycle workflows treat a leaver as someone who leaves the scope of needing access, a move that might require removing it, and the badge record should carry the same removal trigger from the day it is created. Start the work from the current employee event, reject an event with a missing or contradictory location, and never guess a building from the manager's office or the employee's time zone.

Arrival guidance that cannot go stale

Store arrival guidance as maintained knowledge with an owner and a review date: arrival window, public entrance, reception procedure, required identification, accessibility route and the fallback contact. GitLab's onboarding handbook ends its onboarding page with a last-modified line. Give your arrival page the same visible marker, and have the assistant read it. Link the task and the event to one current page, and when the office, the reception hours or the pickup process changes, edit that page and do not paste replacements into chats. The response policy then follows the verified state:

def workplace_answer(p):
    if p["activation_state"] != "active":
        return safe_status(p), staffed_fallback(p)
    if p["delivery_state"] is None:
        return "Access is active; credential delivery is unresolved", route_to(p["fallback_owner"])
    if arrival_guide_is_stale(p["arrival_guide_version"]):
        return "Detailed arrival instructions are unavailable", route_to(guide_owner())
    return pickup_and_arrival_guidance(p), ask_to_confirm_entry(p)

Adjust it to your access technology and local procedure. Publish a state to the company brain only after the source system confirms it, with a timestamp and a source owner, and when the integration is unavailable, say that verification is unavailable instead of reusing the last successful state.

Take a hire whose workplace changes three days before the start date. The HR system sends a new workplace code, the lifecycle workflow cancels the old request and opens one for the new office, and the badge already printed is not active at the new site. The company brain sees authorization_state: pending, suppresses the old arrival page, says access is being updated and gives the service route. Once the workplace owner approves the new profile, activates the badge and assigns a pickup, the projection updates with the new guide version, and the entrance and pickup instructions appear. Without the state model, the assistant would repeat whichever office instruction was indexed last.

Confirm the entry

The last state is not badge_sent. It is a bounded confirmation that the hire reached the required work area, or that a named owner resolved the exception. Ask the hire to confirm after the expected arrival time. Where the access system can emit a single first-entry event with a timestamp, and no door, zone or person detail, prefer that to the hire's memory. Either way, record the failed dependency, owner and resolution if entry fails, and keep raw door events out of the onboarding record.

• If the workplace is missing, stop the request and ask People Operations to correct the record.
• If the start date moves, recalculate activation and delivery timing and invalidate old guidance.
• If approval is delayed, show pending and the staffed fallback, never an estimated approval.
• If a printed badge is not active, readiness stays false until activation is confirmed.
• If a badge is lost before arrival, disable the credential through the security process and issue a replacement path.
• If the entry test fails, open an incident with the profile, credential state and owner, and keep restricted facility details out of the onboarding chat.

Test each supported workplace and profile with a test identity or an approved test credential, never a new hire's badge. A valid event must create the right request, a missing location must stop it, and a location change must remove the old request and create the new one. The employee view must never expose restricted zones, a stale arrival guide must block detailed instructions, the fallback desk must be staffed during the stated arrival window, and a successful entry must close the task without copying access logs.