Note /
What a posture document looks like
Other notes describe the document you sign at handover. This one shows the posture part of it: the posture document for a fictional Team Install on QM, redacted where the install would fill in names, so you can read what you would be signing before you order.
What you are looking at
A Team Install on QM with Slack as the surface, for two jobs, working support tickets and producing scheduled reports and watches, puts two add-ons on the order. The document below is derived from that order the way the build packet is, so the access rows and the actions that wait for a person are exactly the ones such an order produces. Nothing here has been deployed. The client, the order reference, the people, the pinned version and the dates are redacted in square brackets, and the agents table is filled during the install once each workspace has an owner. The framework setting line under section 1 is read from the framework’s own documentation and checked on the install; there is more on that below. The handover document you sign is described in another note; this is the posture document that goes with it and is signed at the same handover.
Security posture document
This document records exactly what the deployment will and will not do. Optaimi’s obligation is hardening to this posture plus training and guidance. After signature the client is responsible for how the agents are used.
1. The default this deployment ships with
Agents get access to the tools their job needs and nothing else. The allowlist is exactly the access table in this document. Actions with consequences wait for human sign-off. A dangerous-equivalent posture is refused and is not offered below.
Framework setting: Organisation posture Strict (every tool call pauses for approval); predeclared command policy on; Dangerous never enabled.
2. Agents
| Agent | Jobs | Operator or owner |
|---|---|---|
| [agent per workspace] | Work support tickets; produce scheduled reports and watches | [owner] |
3. What each agent can reach
| Integration | Read | Write |
|---|---|---|
| Helpdesk connection (Zendesk, Freshdesk) | yes | gated |
| Scheduled automations pack (crons, reports, watches) | yes | gated |
Anything not listed is not reachable. Adding to this table is a change the client requests in writing.
4. Actions that wait for a person
| Action | Who approves | Where the approval happens |
|---|---|---|
| Sending a message to anyone outside the team | [person] | [channel or UI] |
| Writing to Helpdesk connection (Zendesk, Freshdesk) | [person] | [channel or UI] |
| Writing to Scheduled automations pack (crons, reports, watches) | [person] | [channel or UI] |
| Spending money or committing the company to anything | [person] | [channel or UI] |
| Deleting or overwriting data | [person] | [channel or UI] |
| Running a destructive command | Refused outright, not approvable | n/a |
| Any dangerous-equivalent posture | Refused outright, not approvable | n/a |
5. Deviations from the default chosen by the client
None recorded.
6. The buyer’s instruction (from the order)
Triage the Zendesk queue each morning and post a Monday summary of open work to the ops channel.
7. Residual risk
Agentic systems can be manipulated through the content they read (prompt injection) and through people (social engineering). The posture above limits the blast radius; it does not remove the risk. Consequences of prompt injection or social engineering after sign-off rest with the client, and the training session covers how to spot both.
8. Signatures
What gated means for the person approving
Every row of the access table reads yes and writes gated. A write waits for the person named in the who-approves column, in the place named beside it. Both are placeholders in this sample because the install fills them in, and they are the two things a buyer most often asks about after reading the table. Two rows in section 4 have no approver at all. Running a destructive command and a dangerous-equivalent posture are refused outright rather than routed to anyone, the refusal that what hardened means describes.
Why the deviations section is empty
It is empty because the order has nowhere to loosen anything: the buy flow derives the posture from your answers and every order starts from the hardened default. A deviation is something you choose before or during the install, and this section is where it is recorded and signed. Each row records one change and the reason you gave for it. Optaimi writes the risk against it and you initial the row. After handover the permissions are yours to review and revoke, and you can tighten or change the default from there; the section records only the choices made before the signature.
Where the framework setting line comes from
The one line in the document that is specific to QM is the framework setting under section 1. QM’s own documentation describes an organisation posture called Strict, in which every tool call pauses for approval, and one called Dangerous, which is the one this service refuses. The line is checked against the framework during the install, before the handover at which the document is signed, and it stays as written only if it holds. The pinned version in the header is the version it was checked on. Where responsibility sits once the document is signed is the subject of what you sign at handover.