Post Orders and Incident Logs: One Agent Memory for Security Firms

An AI agent for a security guard company works best when post orders and incident logs share one memory, but each kind of record keeps its own status. Post orders are the approved standing rules for a site, and incident logs are the timestamped record of what happened under those rules. The agent can read both, explain what applies at a given post, and draft updates, while a named supervisor approves any change that alters how a guard acts or what a client is told.

Key takeaways

• Post orders are the standing rules for a site, and incident logs record what happened under them. Keep both in one memory, but give each entry a clear status such as approved, draft, or closed.
• Let the agent read, summarize, cross-reference, and draft. A named supervisor approves every change to a post order, every client notice, and every final incident classification.
• Start with one site and one role. Pick a single, measurable check, such as whether each shift handover cites the current approved post order version.
• Treat agent permissions as a list that someone reviews on a fixed schedule, not as a setting configured once and forgotten.
• Expect the first weeks to expose gaps in the source documents, such as outdated gate codes or contacts that no longer work. Those gaps are useful findings, not failures of the agent.

What post orders and incident logs contain

Post orders are the instructions a guard follows at a specific site. They usually cover the hours of coverage, patrol routes and frequency, access procedures for employees and visitors, restricted areas, equipment, escalation contacts, and what to do when something falls outside the routine. They change when the client changes a process, when the site layout changes, or when a previous incident shows that a rule was unclear.

Incident logs are different in character. Each entry has a time, an observer, a category, the observation itself, the action taken, who was notified, and whether the matter was closed and by whom. A single log entry often reveals a deviation from a post order, such as a door left unlocked during a patrol or a visitor admitted without the required check. That connection is the reason the two records belong together, even though they have different owners and change at different speeds.

Why one memory, with separate status for each record

An agent that answers questions about a site needs to know which version of the post order is current and which log entries support a particular conclusion. If the agent retrieves an old gate procedure from a binder scan, or treats a draft note as an approved rule, the guard on shift receives the wrong instruction. The practical solution is a versioned post order store with an approval field, an append-only incident log, and clear labels on anything the agent generates.

Retrieval-based designs are well suited to this problem because the agent answers from documents it can point to instead of from general knowledge. The AWS overview of retrieval-augmented generation describes the basic pattern. For a security firm, the important rule is that every answer should name the post order version and the log entries it relied on. If it cannot name them, the answer belongs in a review queue, not in a message to a guard.

When the memory is built this way, the agent can answer questions such as which patrol applies on a holiday, whether a similar incident happened at the same site in the past, and what the open follow-ups are from the last week. It cannot silently change the rule itself.

Approval gates: what the agent does alone and what a person must approve

The most useful decision a security firm can make early is a written approval matrix. It should be short enough that supervisors actually read it. A workable version has three tiers.

• The agent may act alone on read-only and internal tasks: summarizing a shift log, flagging a missed patrol entry, drafting a handover note, and searching past logs for comparable incidents.
• The agent drafts and a supervisor approves before anything takes effect: changes to post orders, escalation contacts, incident categories, and any message to a client about an incident.
• The agent never acts on its own: contacting public authorities, editing a closed log, changing guard credentials or access rights, and altering scheduling or pay rules.

The principle behind the matrix is least privilege. The OWASP authorization guidance is a useful reference for deciding who and what may perform each action. The agent should hold read access to the approved post order store and the closed log archive, and write access only to a draft queue. Anything that changes the live rule should require a human identity to approve it.

The agent should be able to propose a change to a post order. It should not be able to publish one.

Treat log text as data, not as instructions

Incident logs contain free text written by guards, visitors, and sometimes people outside the firm. Some of that text will be inaccurate, and some may contain instructions aimed at an automated system. The OWASP guidance on prompt injection prevention explains why the agent must treat any retrieved text as content to analyze rather than commands to follow. This matters in a security setting because a log entry that appears to authorize a new access procedure could mislead an agent that is not careful.

The practical safeguards are straightforward. Actions triggered by log content must go through the approval queue. The agent should not be able to send messages or change records based only on what a log entry says. Reviewers should see the source entry next to every draft change.

Illustrative scenario: A guard writes in a log that a visitor said the gate code has changed. The agent reads the entry, finds that the post order lists the old procedure, and drafts an update to the gate procedure with a link to the source entry. Because post order changes require supervisor approval, the draft waits in the review queue. The supervisor confirms the change with the site manager before anything is published, and the agent's draft is marked as unverified until then.

What a security firm should set up first

The first engagement should be small enough to finish and specific enough to judge. The following sequence is a practical starting point.

• Choose one site with a current, approved post order set and a reasonable history of logs.
• Convert the post orders into one document format with fields for version number, approval date, approver, and the site they apply to.
• Define the log schema: time, site, observer, category, action taken, notifications sent, and the name of the person who closed the entry.
• Write the approval matrix in plain language and name the person responsible for each tier.
• Grant the agent read access to the approved post order store and the closed log archive, and write access only to a draft queue.
• Set one success check that a supervisor can verify in a few minutes, such as every handover summary citing the current post order version and every draft change linking to its source entry.
• Schedule a permission review and a short evaluation each month, and record every case where the agent was wrong.

Avoid the temptation to connect every site, client, and channel at once. A firm that starts with one site learns more from a single week of drafts than from a month of planning meetings.

How to tell whether the agent is reliable

Reliability for this kind of agent is measured by the quality of its answers and the traceability of its actions. Build a small set of test questions from real past incidents where the correct answer is known. Include questions where the right response is to say that the post order is unclear or that no matching entry exists. The OpenAI guide to evals and the Anthropic writing on evals for agents both describe the general method: define expected behavior, run the same cases repeatedly, and review failures by category.

Observability is the second half. For each agent action, record which post order version was retrieved, which log entries were used, what was drafted, and who approved it. The OpenTelemetry concepts documentation describes the general idea of tracing and logging system behavior so that problems can be found and explained. A security firm needs that trail for internal review and for any client question about how an incident was handled.

The NIST AI Risk Management Framework is also useful here because it frames risk as something to map, measure, and manage over time, not as a one-time sign-off.

How Be Human handles this in managed operations

Be Human designs and implements personalized AI infrastructure for companies, with the agent's identity, memory, channels, tools, permissions, and operating context kept under human control. In a first engagement, Be Human defines one useful role, the post order and log memory it needs, the approval gates, and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response, and controlled improvements to the agent. The service is remote and available in English and Portuguese. If you want to find the first task worth handing to an agent in your own operation, the free Be Human AI diagnostic is a practical place to start.

Frequently asked questions

Can the agent update post orders directly when a guard reports a change? No, and it should not be able to. The agent can read the reported change, find the affected post order, and draft a revision with a link to the source entry. A named supervisor should approve the revision before it becomes the current version that guards follow.

Do post orders and incident logs need to live in the same system? They need to be connected, but they do not have to be stored in one application. What matters is that the agent can reach both through permissions that match their status, with approved post orders readable as the live rules and closed logs readable as the history. The approval queue should be the only place where the agent's proposed changes appear.

What should a security firm set up before connecting any agent to its records? Begin with one site, a single approved post order set in a consistent format, a log schema with clear fields, and a written approval matrix. Add a single success check that a supervisor can verify, and schedule a monthly review of permissions and of the agent's errors. Only after that should the firm consider a second site or a second channel.

How does a firm know whether the agent is making fewer mistakes over time? Keep a fixed set of test questions drawn from real past incidents, including questions where the correct answer is to say the information is missing. Run them on a regular schedule and record each failure by category, such as wrong post order version or an unsupported conclusion. Compare the results across reviews and use the findings to decide what to improve next.

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