AI for a Security Guard Company: Shifts and Incident Reports

An AI for a security guard company works best as an administrative agent. It answers routine shift coverage questions from the approved schedule, turns an officer's raw notes into a structured incident report draft, and prepares client updates for review. It does not assign posts, judge incidents or contact clients on its own: supervisors keep every operational decision, and the agent removes the retyping and chasing around them.

Key takeaways

• Start with three narrow jobs: shift coverage answers, incident report drafts and client update drafts. Each has a clear input, a clear output and a human reviewer.
• The agent reads the published schedule and records. It does not edit rosters, approve swaps or change post orders.
• Incident drafts must separate what the officer observed from what anyone concluded. Unknown fields stay marked as unknown.
• Nothing reaches a client without supervisor approval until the company has reviewed a long run of drafts and chosen, in writing, which routine messages may go out directly.
• Judge the agent by observable results: fewer unanswered schedule messages, faster first drafts, fewer corrections at review.

What can an AI agent actually do for a security guard company?

A guard company runs on information that moves between people at awkward hours. Officers ask where they are posted. Supervisors collect notes from a phone, a radio log or a paper pad. Account managers wait for a summary so they can answer a client. Much of that work is not judgment. It is lookup, formatting and follow-up, and that is where an agent helps.

Three jobs fit well:

• Answering shift coverage questions from the current schedule, and routing anything that needs a decision.
• Drafting incident reports from an officer's account, asking for missing details and producing a consistent format.
• Preparing client updates from approved reports, in the tone and detail the contract allows.

What the agent should not do is just as important to define early. It should not decide whether to dispatch, escalate, call emergency services or release a guard from a post. It should not interpret an event as a crime, assign fault or promise a client anything. Those decisions belong to supervisors and, where relevant, to managers and legal counsel. The framing in Anthropic's [guidance on building effective agents](https://www.anthropic.com/engineering/building-effective-agents) is useful here: prefer the simplest workflow that does the job, and add autonomy only where the risk is understood.

How should an agent handle shift coverage questions?

Most schedule messages are repetitive. Where am I tomorrow? What time does the site start? Is the Saturday night post filled? Can I swap with a colleague? An agent can answer the first kind directly and structure the rest for a human.

The key design choice is read-only access. The agent reads the published schedule from the system of record and quotes it, with the date the schedule was last updated. If the schedule is missing or unclear, the agent says so and passes the question to the scheduler. It never guesses.

Things the agent can answer alone:

• An officer's own upcoming shifts, start times and site names.
• Published post orders that the officer is already authorized to see.
• Whether a post currently shows as filled or open on the schedule.
• Standard company policy questions, such as how to request time off or who to contact for payroll.

Things it turns into a structured request for a supervisor:

• Swap and cover requests, with the people, post and date written out, and a note on any rule that might apply, such as rest periods or site certification.
• Late or absence notices, forwarded with the time received.
• Questions about another officer's schedule or contact details, which the agent declines to share.

Identity matters. The agent should respond only through channels linked to a known employee, and it should treat unfamiliar senders as unverified. Sensitive material such as alarm codes, key locations and access instructions should not live in the agent's memory unless the role truly needs it, and then only with permissions limited to the people who already hold that access. The OWASP [authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) on least privilege and deny-by-default applies directly: the agent should be able to see only what a given user is allowed to see.

How does incident report drafting work without changing the facts?

A good incident report is plain, timed and specific. A weak one is vague, late or full of opinion. Officers are often tired, writing on a phone at the end of a shift, and supervisors spend time reshaping the text. An agent can take that first pass.

The workflow starts with the officer's own account, in whatever form they send it: a voice note transcript, a few lines of text, a list. The agent then does four things:

• Structures the account into the company's report template: site, date, times, people involved, what was observed, actions taken by the officer, who was notified.
• Asks follow-up questions for gaps, such as the time something was noticed or whether a supervisor was informed.
• Keeps the officer's original wording attached to the draft, so a reviewer can see what was changed.
• Marks anything missing as unknown instead of filling it in.

The discipline is separating observation from interpretation. "The rear door was found open at the time of the patrol" is an observation. "Someone broke in" is a conclusion the report should not contain unless a person with the authority to say so has said so. The agent should be instructed to flag speculative language and offer a neutral rewrite, which the officer or supervisor accepts or rejects.

A few guardrails keep reports trustworthy:

• Times and names come from the officer's input or from logged systems, never from the agent's inference.
• The agent cannot modify a report after a supervisor marks it final. Corrections create a new version with a visible history.
• Personal data about injured people, witnesses or third parties is limited to what the template requires.
• Content from outside sources, such as a forwarded message or a visitor's note, is treated as material to summarize, not as instructions. The OWASP [prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes why this separation matters.

An illustrative scenario: a propped door and an unknown vehicle

This is an illustrative example, not a real case.

An officer on an overnight patrol at a commercial site finds a fire door propped open with a wedge and notes an unfamiliar vehicle parked near the loading area. They send a short message to the company channel. The agent replies with three questions: what time was the door found, was the vehicle still there when the patrol ended, and has a supervisor been informed. The officer answers the first two and says the supervisor was called.

The agent produces a draft report. Times, location and actions come directly from the officer's answers. The vehicle's plate is listed as not recorded. The cause of the propped door is listed as unknown. The draft goes to the duty supervisor, who corrects one time, adds a note about a call to the site contact and marks the report final.

Only then does the agent prepare a client update draft: what was found, what the officer did, what is being checked next. The supervisor reads it, removes a sentence that goes beyond the facts, and sends it. At no point did the agent decide whether the event was serious, whether to call anyone, or what to promise the client.

What belongs in a client update, and who approves it?

Clients want to know that someone saw the issue, that it was handled and what happens next. They do not want a flood of messages, and they do not want unverified claims. The contract usually defines what the guard company owes in notifications, and the agent should be configured around that, not around a general sense of helpfulness.

A useful pattern uses three kinds of message:

• Routine confirmations, such as shift start, patrol completion or a scheduled visit finishing. These are low risk and can be drafted from logs.
• Incident notices, drafted from an approved report and always reviewed by a supervisor before sending.
• Periodic summaries, assembled from final reports for an account manager to read and adjust.

The agent should avoid language about fault, liability, insurance, legal exposure or the behavior of named individuals. If the client replies with a question that touches any of these, the agent logs it and hands it to a human without answering. If a client asks for something outside the contract, such as an extra patrol or changed post orders, the agent records the request and routes it to the account manager.

The same shape of work appears in other field-based services, and you can compare how it is handled in AI for cleaning company operations and in AI for a home care agency, where visit notes and family updates carry similar review requirements.

Decision guide: what the agent does and what stays with people

Use this guide as a starting point and adjust it with your operations manager and legal adviser.

• The agent may act alone: quote the published schedule, share an officer's own details, explain a published policy, ask follow-up questions for a report, format a draft, remind an officer of an unfinished report.
• The agent drafts and a human approves: incident reports, client incident notices, periodic client summaries, swap requests prepared for the scheduler, handover summaries between shifts.
• Humans only: assigning or moving posts, approving swaps and overtime, deciding to escalate or call emergency services, judging whether an event is an incident, discussing liability, disciplinary matters, and anything involving law enforcement or insurers.

Write this guide down and put it where supervisors can find it. When a new situation appears, the default is the more cautious column until someone decides otherwise. Record that decision, so the boundary changes on purpose and not by drift. The NIST [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) takes a similar approach: define the context, map the risks, assign accountability and review over time.

A step-by-step plan for a first engagement

Do not start with every site and every message type. Start with one role and prove it.

• Step one: choose one role, for example the shift and report assistant for a small group of sites. Name the supervisor who owns it.
• Step two: list the sources it may read, such as the published schedule, the report template and approved policies. Leave out everything else.
• Step three: define the approval boundaries using the decision guide above, and write them in plain language.
• Step four: set the success criterion in observable terms, such as how long schedule questions wait for an answer, or how many drafts need substantial correction at review.
• Step five: run it in draft-only mode. Every output is reviewed, and reviewers note what they changed and why.
• Step six: review the changes weekly. Update templates, instructions and permissions where patterns appear.
• Step seven: decide, in writing, whether any low-risk routine messages may be sent without review. Keep incident notices under review.

This kind of recurring work also benefits from the habits described in AI agents for operations teams, such as scheduled reports and clear ownership. If your company must show evidence of how decisions were made, AI for compliance teams covers the records and review trail you will want.

How does Be Human's managed approach handle this?

Be Human designs and operates the agent as infrastructure with defined limits. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. For a security company that usually means read-only access to the schedule, a report template, a channel for officers and a review queue for supervisors. Managed operations can include monitoring, recurring evaluations, permission review, integration maintenance, incident response and controlled improvements. The company keeps control of identity, permissions and what the agent may send, and supervisors remain the decision makers.

Frequently asked questions

Can an AI agent replace a dispatcher or control room operator? No. Dispatch involves live judgment, urgency and accountability, and those stay with people. The agent supports them by handling routine questions and paperwork so they have more time for decisions.

Should the agent send updates to clients directly? Not at the start. Drafts should go to a supervisor or account manager, who approves or edits them. After a long period of reviewed drafts, you may choose to allow a narrow set of routine confirmations to go out directly, while incident notices remain under review.

How do we protect sensitive information in incident reports? Limit what the agent can read and what it keeps in memory, and use the report template to collect only what is needed. Give access by role, keep a version history, and review who can see which sites and reports. Decisions about retention and disclosure should follow your contracts and the rules that apply where you operate.

How do we know the agent is working well? Measure the agent against outcomes you can observe: how quickly officers get schedule answers, how often supervisors correct drafts, and whether reports have fewer missing fields over time. Review a sample of conversations and drafts regularly, and adjust instructions or permissions when you see repeated errors.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.