Governance of Paperclip AI agents: where controllability breaks
The controllability of an AI agent breaks not where people look for it. Prompt instructions describe the desired behavior but do not constrain the actual perimeter of actions: the agent gains access to tools and then decides on its own which calls to make.
The first typical failure is going beyond the agreed perimeter: the task was "prepare a draft reply to the client," but the agent, through a chain of steps, reached the point of sending the email and editing a record in the CRM.
The second is inheritance of excessive privileges: the agent runs under a service account that has more access than its scenario requires, and any logic failure immediately becomes a failure with real consequences.
The third failure is quieter and therefore more dangerous — duplication of operations. The agent has no reliable representation of what it has already done: on a repeated request, timeout, or restart, it performs the action a second time.
For reading, this goes unnoticed; for a charge, a send, or the creation of a record, it no longer does. Add to this the absence of tracing: when an incident has occurred, there is no way to reconstruct exactly which call was made and on what basis.
None of this can be cured at the prompt level, and this is the key point. A prompt is text in the model's context, not an enforcement mechanism: it can be bypassed by the wording of the task, by injection in the data being processed, or by ordinary ambiguity.
Constraints must be imposed outside the model — by things the agent physically cannot bypass: separation of accounts by scenario, an explicit list of permitted tools and parameters, idempotent keys on mutating operations, and a mandatory log of every call tied to the task.
Governance of Paperclip AI agents is built precisely around this principle: the agent's action perimeter is defined by configuration and permissions, not by the text of an instruction, and the controllability of AI agents is tested against attempts to go beyond it. Below we break down how this works in practice and which failures each level of constraint closes.
What a governed loop provides for AI agents
A governed loop is a set of policies that describe what an agent is allowed to do, what requires human confirmation, and what is forbidden entirely.
Policies live separately from the scenario code: they can be changed without rebuilding the agent, and they apply to all scenarios uniformly.
This is precisely what turns a collection of disparate experiments into a system where every action of the agent is explainable and reproducible.
Approval of an agent scenario ceases to be manual work from scratch. When ready-made policy templates exist — data access levels, action limits, mandatory confirmation points — a new scenario is assembled from proven blocks.
Approval time is reduced many times over: the engineer describes what the agent does rather than proving why it is safe. The reviewer sees a familiar structure and evaluates only deviations from it.
The share of manual checks drops predictably. Policies remove routine work from humans — typical operations within permitted boundaries are performed by the agent itself, and only actions beyond the limits go to confirmation.
The more precisely the boundaries are described, the fewer checks are needed manually, and the higher the throughput of the loop without an increase in risk.
Separately, a class of agent failures related to unauthorized actions is closed off: going beyond the agreed scenario, accessing data outside the permitted perimeter, irreversible operations without confirmation.
Such actions are blocked at the policy level, not after an incident. Each denial is recorded with context — it is visible which rule was triggered and at which step, so the review takes minutes rather than days.
In total, a governed loop delivers three measurable shifts: approval of a new scenario is accelerated, the share of manual checks decreases, and an entire class of incidents ceases to be reproducible.
This is not a one-time setup — policies are refined as new scenarios appear, and the loop remains governable as the number of agents grows.
Agent operating modes: isolated, delegated, autonomous
The launch mode is not a "just in case" setting, but the trust boundary between the agent and your systems.
The same scenario in isolated and autonomous mode differs not in speed, but in who is responsible for the consequences: a human at every step or a policy hardcoded into the configuration.
Below are three modes that are actually chosen between when implementing governance policies for AI agents Paperclip.
| Mode | When it fits | Limitations |
|---|---|---|
| Isolated agent launch | First rollout of a scenario into production, sensitive data, incident investigation | The agent does not write to target systems — it only reads and suggests; the result is transferred manually |
| Delegating tasks to an agent | Routine operations with a clear checklist: preparing changes, reconciliation, drafts | Every action with a side effect requires confirmation; long chains of steps break up into manual pauses |
| Autonomous agent | An established process with reversible actions and working rollback | Limitations are set by policy: allowed tools, limits on volume and frequency, mandatory action log |
What changes when switching between modes
A transition is always an expansion of privileges, and it should be done one step at a time. First the scenario lives in isolation until it becomes clear that the agent consistently hits the target.
Then delegation is enabled: the agent prepares an action, a human confirms — at this stage statistics are gathered on which steps people accept without edits and which they roll back.
Where modes mix
Within a single process, modes often coexist: reading and analysis — autonomously, writing to target systems — with confirmation, and operations with access permissions and configurations — only in isolation. This separation is set by policy at the tool level, not by trust in a specific run.
How we implement governance policies: stages of work
Implementing governance policies for AI agents begins not with writing rules, but with an inventory: which agents are running, which systems and data they have access to, which actions they perform autonomously, and which only after human confirmation. Without this picture, any policy turns into a set of good intentions that cannot be verified.
Next, we build the agent's role scheme: what it is allowed to do by default, what requires approval, and what is completely prohibited.
The role is described formally — through the data scope, type of operations, and escalation conditions — so that the rule can be applied machine-wise rather than interpreted at the operator's discretion.
- Inventory of AI agents and their actions. We compile a registry: the agent's purpose, owner, connected systems, list of operations, and trigger conditions. We record where the agent acts on its own and where a human is needed.
- Classification of data and risks. We mark which data the agent accesses and what the consequences of an error are — from harmless to irreversible. This sets the level of control for each role.
- Designing the role scheme. For each agent, we describe permitted actions, limits, escalation conditions, and mandatory confirmation points. Roles become the foundation of the policy.
- Writing and versioning policies. We formalize the rules as configuration under version control: a policy change is a separate edit with a history and an owner, not a verbal agreement.
- Testing policies on a staging environment. We run scenarios: we try to push the agent beyond its role, check that restrictions trigger and that escalation works correctly. We find gaps before production.
- Deployment and monitoring. We enable the policies in the working environment, set up logging of the agent's actions and alerts about attempts to go beyond what is permitted.
- Handover of regulations and training of responsible staff. We hand over the documentation, the agent registry, and the procedure for changing policies, and we conduct training for owners and on-call staff.
After the handover of regulations, the client's team can add agents and change roles on its own without losing control. Describe your agents and current constraints — we will come back with an assessment and a work plan.
Access policies and roles for Paperclip AI agents
The access perimeter is built around three entities: the agent's role, the permitted action, and the confirmation condition.
A role describes a class of tasks — reading data, preparing drafts, modifying records, calling external systems — and is inherited from a template rather than assigned manually to each agent.
An action is bound to a role and to an object: an assistant agent has access to the knowledge base, but writing to billing is closed. The confirmation condition determines when an operation goes to a human: amount, irreversibility, external recipient.
The role matrix is a "role × action × object × mode" table, where the mode takes one of the values: allowed, forbidden, requires confirmation. This format is readable by both an engineer and the security service, and does not fall apart when new agents are added. Below is what is included in the perimeter.
- Role and permission matrix: inheritance from templates, deny by default, explicit exceptions with justification.
- Action confirmation rules: thresholds by volume and irreversibility, a mandatory human for external sends.
- Agent action logging: who initiated, which tool was called, what data was read, what result was obtained.
- Limits on operations: call frequency, sample volume, number of records per session, depth of the chain of autonomous steps.
- Procedure for revoking authority: role change, agent suspension, full shutdown with log retention.
- Environment separation: a test perimeter with reduced rights and a production one with full control.
- Review regulation: scheduled revision of rights and unscheduled — after an incident or a change of process owner.
We design logging so that a record reconstructs the course of a decision, not just the fact of a call. We store the agent identifier, the version of its instructions, input data, intermediate steps, and the outcome — this is sufficient for incident investigation and for audit.
Revocation of authority works in three steps: removal of the role, stopping active sessions, blocking the agent's credentials. The log remains immutable — otherwise the investigation loses its meaning.
We formalize policies declaratively, in configuration next to the agent's code, so that a change of rights goes through review like an ordinary change.
We work with Paperclip and adjacent agent orchestration environments — we transfer rules between perimeters without rewriting from scratch.
Case study: how the share of manual agent reviews was reduced
The client is a product team with several AI agents in production: one handled incoming requests, the second prepared data exports, the third edited product cards.
The agents wrote directly to production systems, and every action they took went through manual review by an operator before being applied.
At scale, this meant up to a hundred reviews per day, and incident triage — rolling back an extra record, accessing an unauthorized source, re-running after a failure — took the on-call engineer hours.
Paperclip was deployed as a governance layer between the agents and the systems: every action is first described by a policy, and then either executed or sent for confirmation.
Critical operations — writing to reference data, bulk changes, access to personal data — require explicit human approval. Everything else passes automatically, but with a full audit log: who initiated it, which rule authorized it, what changed.
What was changed
- Introduced roles and access scopes for each agent instead of shared credentials.
- Described policies for typical actions: read, write, bulk operations, external calls.
- Configured mandatory confirmation for operations above a given impact threshold.
- Enabled logging with each action tied to a rule and an initiator.
- Added automatic rollback for operations that passed without confirmation by mistake.
What was achieved
The share of manual reviews dropped roughly fourfold: the operator only looks at the actions flagged by policy as critical, not the entire stream. Incident triage now takes minutes — the log shows which rule fired and at which step the agent deviated from the scenario. Recurring failures were closed by fixing policies rather than by modifying the agent's code.
A separate effect is the predictability of changes. Previously, some incidents surfaced after the fact, when the data had already spread across systems; now an action is either confirmed or not executed, with no intermediate states. The governed loop removed the need for the team to constantly stand watch over the review queue.
How does Paperclip AI agent governance differ from conventional logging?
Logging answers the question "what happened" — it records events after the fact and changes nothing in the agent's behavior. Paperclip AI agent governance works differently: policy is embedded at the moment an action is executed and can stop it. The difference is fundamental — a log records damage, while governance prevents it from happening.
Passive recording is simple: the agent calls a tool, the event goes to storage, and an analyst reads it hours later. By that time, the email has been sent, the database record has been changed, the external service has been paid for.
Logging agent actions is useful for investigation and audit, but it is not a control point — it has no authority to say "no."
Active agent governance places policy between the model's decision and its execution. Every call passes through a verification layer: whether the action falls within the permitted scope, whether it stays within limits, whether critical actions require human confirmation. If a rule is violated, the call is blocked before anything happens, not after.
The key difference is reversibility. Logs do not roll back a sent email or restore deleted data. Policy, however, can revoke permissions: an agent's access to a tool is closed in a single step, and all subsequent attempts are rejected until access is explicitly restored. This turns an incident from a post-mortem into prevention.
In practice, both mechanisms complement each other. Policy decides what an agent may do and what requires confirmation; the log shows how those decisions were made and where the rules took effect.
Without the first circuit, the record remains mere evidence; without the second, governance loses the trail for audit and threshold tuning.
What to do if agents are already deployed and running
Introducing policies into a live environment begins not with prohibitions, but with an inventory of existing agents.
Until there is a complete list — who is running, what access they have, which systems and data they touch, which actions they perform automatically — any blind restriction breaks the process. The inventory produces a map: agent, owner, area of responsibility, current permissions.
From there it becomes clear where the real risk is and where there are excessive privileges inherited by inertia.
Phased restriction is structured so that the environment does not stop. First we introduce an observation mode: the agent works as before, but every action is written to a log — this is how the actual picture of behavior is gathered, rather than assumptions.
Then we narrow permissions to the minimum necessary, action by action, and at each boundary we place a checkpoint: if the agent goes beyond the agreed perimeter, a block and a notification to the owner are triggered.
Rollback to the previous permission level remains available, so an unsuccessful restriction does not turn into an incident.
Checkpoints are not only prohibitions but also confirmations: critical operations go through explicit approval, the rest — automatically within the policy. This order makes it possible to introduce rules on a live system rather than stopping it for a "big migration."
Can policies be introduced without stopping running agents?
Yes. Observation mode and phased narrowing of permissions do not interrupt current processes: the agent continues to perform tasks, and restrictions are added one checkpoint at a time.
If a new policy interferes with a working scenario, permissions are returned to the previous level without downtime.
What to do if some agents have no owner and no documentation?
This is a typical situation in a live environment. For such agents, we first record actual behavior from the logs, assign a responsible person, and only then restrict permissions.
Agents without an owner and without a clear area of responsibility are decommissioned last — after their functions have been covered.
Let's discuss the task: we'll design a control perimeter for your scenario
The first conversation is not a presentation but a breakdown of the scenario: who initiates the agent's actions, which systems it gets access to, what is considered unacceptable, and who is responsible for an incident.
The answers determine the perimeter: where we enforce policy, where we keep a human in the approval loop, and where the agent operates autonomously with a decision log.
Next, we clarify the constraints: what data the agent sees, what it writes back, and how its rights are revoked when an employee's role changes.
Separately, we discuss rollback — how to quickly stop the agent and return the system to its original state if its behavior deviates from expectations.
After the conversation, we come back with an assessment and a work plan: stages, dependencies, what is needed on your side, and at which step the first working result appears.
The plan is based on your scenario, not a template — so it shows which checks address your specific risks.
- Breakdown of the agent use scenario: roles, triggers, approval points
- List of systems and data the agent gets access to
- Perimeter design: where policy is enforced strictly, where a human in the loop is needed
- Scheme for revoking rights and stopping the agent when behavior deviates
- Requirements for the decision log and incident review
- Draft governance policies for your perimeter
- Stage-by-stage work plan with intermediate acceptance points
- What will be required from your team at each stage
Describe the task in free form — the scenario, systems, and constraints. We'll come back with an assessment and a work plan that can be discussed concretely.
