Praesidia's platform operators are the designated staff responsible for the correctness, security, and health of the entire platform, across every organization. If your organization runs AI agents on Praesidia, a security review will ask three things about those people: how their access is kept apart from yours, which of their actions need more than one of them, and what their access leaves behind for you to inspect. This post answers those three questions. For the controls your own administrators use inside your organization, see plan gating and feature flags; for the general pattern behind the two-person rule, see maker-checker for platform administration.

Operator access is separate from your organization's roles

Operator access is not a role inside any organization. It is granted to named staff accounts in the platform's own configuration, outside the application, and the operator tools check it on each request. A user who is an owner or administrator of your organization holds no operator access, and no role change made inside an organization can grant it.

The operator tools cover what it takes to run the platform: organization and user records, billing, and usage and health signals summarised across organizations, so operators can spot capacity problems and billing anomalies.

What operator access leaves in your audit trail

When an operator opens your organization's record, or looks up users who belong to it, an entry is added to your organization's audit trail naming the operator and what they opened. The entry is written before the data is returned: if it cannot be written, the request is refused.

Not every operator view adds an entry to your trail. The platform-wide list of organizations and the usage and health summary across organizations, for example, do not. Access that does not go through Praesidia's operator tools is not recorded in your organization's audit trail.

Changes that take two operators

Some operator actions change how your organization is governed or what its audit evidence rests on. Made from the operator tools, each of these takes two operators:

  • Governance mode. Your organization's governance mode sets whether Praesidia's governance is off, observing, or enforcing.
  • Signing keys. Under the default configuration, Praesidia signs your organization's audit records with a key that belongs to your organization. Rotating a key is routine maintenance; revoking one is a break-glass action that affects every log entry signed with that key going forward.
  • Erasing a person's data. Erasing a data subject's personal data under GDPR Article 17 cannot be undone once it is confirmed. For the wider compliance picture, see GDPR erasure and EU AI Act readiness.

The two-person rule works the same way for all three. One operator starts the request, which creates a signed approval that expires and can be used once, and other operators are notified. A different operator confirms it; the operator who started the request cannot confirm it. An approval that is not confirmed in time expires, and the change does not happen.

When a two-person change is confirmed, Praesidia adds an entry to your organization's audit trail naming the operator who started it, the operator who confirmed it, and the reason given. That entry can be missed. A confirmed erasure is also recorded with both operators and a list of the personal data it does not remove.

A signed record shows it was not changed afterwards. It does not show that every action was captured. For how to read and check the entries in your trail, see how to audit AI agent activity and tamper-evident audit logs with cryptographic proofs.

Common questions

Can a Praesidia operator read my organization's data? The operator tools cover what it takes to run the platform, including organization and user records, billing, and usage and health. Opening your organization's record or looking up its users adds an entry to your organization's audit trail first, and the request is refused if that entry cannot be written. Not every operator view adds an entry, and access that does not go through Praesidia's operator tools is not recorded in your organization's audit trail.

Can someone in my organization become a platform operator? No role inside an organization grants operator access, owner included. It is assigned to named staff accounts in the platform's own configuration, outside the application.

What happens if a two-person approval is not confirmed? It expires and the change does not happen. If the change is still needed, an operator has to start a new request, so an old approval cannot be used later in changed circumstances.

Can one operator push through a governance-mode change, a key revocation or an erasure alone? No. The operator who starts the request cannot confirm it, and an approval cannot be used twice, so completing the change takes a second operator.

For a security review, the short version is this: operator access sits outside your organization's roles, the changes that matter most take two operators, and opening your organization's record or making one of those changes leaves an entry, within the limits above, in an audit trail your own team can read. For how signing keys protect that trail, see the AI agent audit trail guide.