New: what governed autonomous procurement actually means
Explainer

Security & AI governance: how it works and what to require

In short

Proconomy governs both people and agents through role-based access, per-agent permission sets, policy thresholds and human approval checkpoints. Every material action is explainable, overridable by an authorised person and retained in a complete audit trail, so autonomous execution can be reviewed by security, audit and finance.

See Security & AI governance

Your security team will ask. Every one of these.

The ones that decide whether autonomous execution is authorised at all.

Authority and boundaries

  • What exactly may each agent do?
  • What is the value ceiling on automated action?
  • What cannot be automated under any configuration?
  • How is authority widened, and who approves that?
  • Does segregation of duties apply to agents?
  • Can an agent grant itself additional permission?

Human control

  • Which decisions always return to a person?
  • Can a checkpoint be bypassed under time pressure?
  • How is an override recorded and attributed?
  • What happens when an approver is absent?
  • Can a person stop an action in progress?
  • Who can change the policy configuration?

Evidence and reconstruction

  • Can any action be reconstructed after the fact?
  • Is the reasoning behind a material action retained?
  • How long is history retained, and who sets that?
  • What does an auditor receive on request?
  • Are overrides distinguishable from routine approvals?
  • Is the record tamper-evident?

Data and access

  • Role and entity-based access across views and actions
  • Single sign-on and identity provider integration
  • What data leaves your environment and when
  • Data residency and retention obligations
  • Subprocessor position
  • Incident and vulnerability handling

Eight controls. Each one enumerable.

Role, permission, threshold, policy, checkpoint, escalation, override, retention.

MechanismWhat it has to do
RoleWho may act in this entity, plant and category — applied to people and agents on the same model.
PermissionWhich specific actions an agent may perform, defined as an explicit set rather than a capability description.
ThresholdThe value or risk level at which a person must decide, configured per category and entity.
PolicyThe buying route required for a given combination of value, category, entity and risk.
CheckpointA decision that always returns to a named person and cannot be bypassed by any agent configuration.
EscalationWhere an action goes when it falls outside permitted authority, with the context attached.
OverrideA person may reverse an agent action; the override is recorded with its author and reason.
RetentionHow long the complete action history is held, configured to your policy rather than a fixed default.

A description of what the practice requires, not a feature list.

Same control surface. Tighter settings by sector.

Where the ceiling drops, by industry.

Aerospace and defence

Every departure from the approved supplier list carries named authority and retained conditions, examinable years later.

Medical devices

Qualification scope and quality-agreement obligations are checkpoints, never automated passes.

Automotive

Containment and root-cause acceptance remain human decisions inside the corrective-action sequence.

Regulated groups generally

Retention configured to the longest applicable obligation rather than to a product default.

Five requirements. In writing, before contract.

A capability description is not a boundary.

  1. Require the permitted-action set for each agent in writing. A capability description is not a boundary.
  2. Require a demonstration of an action being blocked at a threshold, with what the approver then sees.
  3. Require an override to be performed and then retrieved from the record with its author and reason.
  4. Require the complete action history for one transaction, in the form an auditor would receive it.
  5. Require a written answer on data residency, retention and subprocessors before contract, not after.

Definitions. Asked and answered.

Security, hosting, encryption, retention and subprocessor detail is handled through enterprise review, where your security team can question it properly. Start at the trust centre and tell us what your review process needs.

Each agent has an explicit permission set covering permitted actions, value limits, data scope and entities. Anything outside it is blocked and escalated, and the block is recorded with the rule that caused it.

Yes, by a person whose role carries override authority. The override, the person and the stated reason are retained alongside the original action.

Every material action, the rule that permitted or blocked it, the approvals given, the exceptions raised and any override, with the context needed to reconstruct the decision.

It applies to agents as well as users. A role or agent that prepares work cannot also hold the approval right for it where your policy separates those responsibilities.

Only roles you authorise. Policy, threshold and permission changes are themselves controlled actions and are recorded, so a change to the governance model is as auditable as a transaction.

AI governance in procurement means defining what software is permitted to do, bounding it explicitly, holding consequential decisions with named people, and retaining evidence that allows any action to be reconstructed. Without those four properties, autonomy cannot be authorised by a security or audit function.

A checkpoint is a decision that always returns to a named person and cannot be bypassed by any automated configuration. In procurement the usual checkpoints are supplier award, contractual acceptance, supplier status change, quality containment acceptance and any departure from policy.

An audit trail is the retained record of what was observed, which rule applied, what each actor did, who approved, what was overridden and on what basis — held per transaction and retrievable long after the people involved have moved on.

By recording the action against the agent that took it and the specific permission that allowed it, alongside the policy configuration in force at that moment. Attribution without the governing rule is insufficient, because it shows what happened but not whether it was permitted.

See it on your own workflow. Not a prepared scenario.

Reference material explains the model. A demonstration on one of your own processes is what settles the internal argument.

Someone from client success replies, not a sales sequence. If we are not a fit we will say so on the first call.