The Architecture of the Agentic IT Engineer

Executive summary

An AI agent in IT operations does not write code in a sandbox. It changes live systems, for organisations that may not trust each other, from a help desk that attackers already call. The labs that build coding agents have spent two years learning what makes an agent safe and useful, and they have published much of it. This paper applies those lessons to IT operations.

Two ideas carry the paper. First, the model is the part of an agentic system you rent; the control system around it, the harness, is the part you answer for. Second, in IT the limit on what an agent may do is mostly authorisation, not capability.

The second idea comes from our own study. We judged every step of the 615 record types in our MSP operating model from its written procedure; nothing was run. 46% of the record types had a tool for every step, but only 13% could be carried out under the model's own approval and identity rules. The gap is set by who must agree and who must prove who they are, and that is where the design work lies (Part III).

The architecture has one governing rule, intelligence proposes; the platform decides, and ten principles in three layers. Each ends with a question you can put to any vendor, including us.

None of this needs a better model. All of it can be checked.

About this paper

This is a reference architecture, not a product description. It sets out what we believe an agentic platform for IT operations should look like, drawing on the published work of the frontier labs, on academic research and on our own experience. It makes no claim about any product's current capabilities, including our own.

It is written for MSP leaders, IT leaders, CISOs and AI leaders. The MSP case is the hardest on tenant isolation, because an MSP's customers don't trust each other. The internal IT case is the hardest on approvals and ownership, because one change may need a business owner, a service owner and an audit trail that outlives the people involved. We treat both. Where the paper says "client", an internal IT reader can read "business unit" or "department"; for "client approver", read "service owner" or "business owner".

The "What we learned" notes come from designing and building an agentic platform for MSP and IT operations, and from repeated adversarial reviews of our own design. They are design experience, not production results. Where we cite a lab, we describe what it reports; vendor reports are evidence about the vendor's own systems, not independent benchmarks.

This paper is the architecture behind two applied papers: The Agentic MSP Engineer, for managed service providers, and The Agentic IT Engineer, for IT departments in large organisations. The appendices hold the detailed comparison of the labs' guidance (A), the evaluation design (B), a mapping to common governance frameworks (C) and a glossary (D).

Part I. Where the field is

1. The harness, not the model, decides what an agent can be trusted with

In 2024, building an agent mostly meant writing prompts. By 2026 the vocabulary had moved twice (Figure 2): first to context engineering, deciding what the model sees at each step (Anthropic, 2025c; LangChain, 2025), and then to harness engineering, designing the whole environment the agent works in. OpenAI describes how its engineers, building a product with its coding agent and no hand-written code, came to see their job as designing that environment: documentation as the system of record, execution plans kept beside the code, and linters and structural tests that enforce the architecture (OpenAI, 2026).

The clearest outside evidence comes from a study of Claude Code by Liu and colleagues, which compared it with two open-source agents, OpenClaw and Hermes Agent (Liu et al., 2026). The authors describe it as one snapshot of one system, reconstructed from extracted source. Three findings matter here:

• The core loop is simple. By a community estimate the study cites, only about 1.6% of the code is decision logic; the rest is operational infrastructure: permissions, context management, delegation, persistence and recovery.
• Safety is deny-first. A broad rule that denies an action is not overridden by a narrower rule that allows it.
• The three systems draw their trust boundaries in different places. Claude Code's boundary sits between the model and the machine: the model is not trusted, the developer's machine is. OpenClaw trusts whoever operates a gateway and does not support sharing one gateway between users who don't trust each other. Hermes Agent keeps a fixed floor of blocked destructive commands that applies in every approval mode.

Anthropic now splits an agent into three replaceable parts: a durable session log, a stateless harness, and a sandbox where tools run (Anthropic, 2026a). It advises removing harness parts as models improve, because each part encodes an assumption about a weakness the model may no longer have (Anthropic, 2026b). That advice concerns scaffolding that helps the model work, such as context resets, task decomposition and retries. It does not concern the gates that decide what the model may do. Those set the floor for safety and reliability, whatever the model.

The lesson for IT operations: the decisions that make an agent safe are harness decisions. A buyer who compares platforms by the model they use is comparing the part that changes every few months.

Across Anthropic, OpenAI, Google, Microsoft and leading independent builders, the published guidance has converged on a short list: start with one agent in a tool loop; treat context as scarce; keep one writer, with read-only helpers and a fresh-context reviewer; package procedures as versioned skills; run tools in isolated environments and keep credentials out of them; assume some prompt injection gets through and limit what it can do; standardise tools on MCP; and evaluate outcomes, repeatedly, with the judge separate from the builder. Appendix A sets out where they agree and where they still differ, with sources. The labs say least about agent identity. Microsoft is furthest ahead, giving agents their own identities in Entra with a human sponsor (Microsoft, 2026a; Microsoft, 2026b), and Google's principles for secure agents start from the same place: every agent needs an identified human controller, limited powers and observable actions (Google, 2025a).

2. IT operations is the harder case

Coding agents have advantages that IT agents lack:

• Undo. Code changes go through version control. A configuration pushed to a firewall, a deleted mailbox or a revoked account may not come back.
• One trusted operator. A coding agent usually works for the developer at the keyboard. An IT agent works for a technician, on behalf of an organisation, with changes signed off by someone else, sometimes for a requester whose identity must be proved, and sometimes through an end user's own hands.
• One tenant. An MSP serves many organisations that don't trust each other from one platform; a large IT department serves business units with their own owners, budgets and rules.
• A test suite. Code has tests that say whether a change worked. In IT, proving a fix means reading the state of a live system afterwards, and some systems take minutes to show it.
• A quiet threat model. The service desk is a door attackers already use. A joint FBI and CISA advisory, first issued in 2023 and updated in 2025 with partner agencies, describes a criminal group calling help desks while posing as employees, to get passwords reset and multi-factor authentication moved to devices it controls (FBI, CISA et al., 2023, updated 2025). An agent that can reset passwords inherits that threat.

The tools an IT agent depends on are targets too. In 2025 an npm package presenting itself as an email MCP server was found adding a hidden copy of outgoing email, addressed to an outside domain, in a release that followed clean ones (Snyk, 2025). Stolen tokens from an AI chat integration were used to take data from hundreds of organisations' customer systems (The Hacker News, 2025a). Researchers showed planted text steering one AI agent on an IT service platform into recruiting a more capable agent to act for it (The Hacker News, 2025b).

Three shifts are under way. Agents are becoming identities: NIST launched an AI Agent Standards Initiative in February 2026, with agent identity and authorisation within its scope (NIST, 2026). MCP has become the common tool interface under neutral governance (Anthropic, 2025h), and the control point is moving to the gateways and registries around it. Assurance is becoming buying language: in the EU, obligations for most high-risk AI systems now begin on 2 December 2027, and for AI built into regulated products in August 2028 (EU, 2026). Most IT-operations agents will not be high-risk systems under the Act, but buyers, auditors and insurers will still ask how agent actions are approved, logged and attributed.

The consequence: everything the labs learned applies to IT operations, and each lesson has to be taken to its strictest form.

Part II. The reference architecture

The governing rule: intelligence proposes; the platform decides. The model never calls a system. It proposes exact, structured actions, and a deterministic layer outside the model classifies, approves, executes and records each one. Policy that lives in a prompt changes when the prompt changes; policy in code does not (Liu et al., 2026), and OpenAI's guide says guardrails do not replace authentication and access control (OpenAI, 2025). Every principle below rests on this rule. Once the model can't act directly, a fooled model is a contained problem: it can propose something wrong, but nothing happens without passing the platform. The safety checks fail closed: if one can't be made, the action does not run.

The ten principles sit in three layers (Figure 3).

However the work starts, a conversation, a schedule, a call from another system, an alert or another agent, one request then moves through those layers in the same order (Figure 4).

Layer one: what the agent knows and sees

Principle 1. Every input is untrusted, and every way out is controlled

The principle. Tickets, emails, alerts, device names, knowledge articles and tool results are text that someone else may have written. Treat them as data, never as instructions, and control every path by which data can leave, outside the model.

What the research says. Indirect prompt injection, planting instructions in content an AI later reads, was demonstrated against real applications in 2023 (Greshake et al., 2023), and benchmarks show tool-using agents still fall for it (Debenedetti et al., 2024). Anthropic reports that, even with improved safeguards, an adaptive attacker still succeeded about 1.4% of the time against its strongest model in browser use, and calls even 1% a meaningful risk (Anthropic, 2025g). Microsoft's guidance assumes some injections will succeed, and limits the damage with access control, code that blocks known ways data leaks out, and human approval (Microsoft, 2025). Willison names the dangerous combination, private data, untrusted content and a way to send data out, and advises against combining all three (Willison, 2025). A help-desk agent has all three by design (Figure 5). CaMeL derives the plan from the trusted request alone, so untrusted data can't change it (Debenedetti et al., 2025), and a catalogue of design patterns sets out the trade-offs (Beurer-Kellner et al., 2025).

What we learned. In a service desk the request arrives in the same channel as the attack, so patterns that trust the user's request don't transfer directly. The platform has to separate what a requester asks from what that requester is entitled to ask: it resolves the requester to a verified identity, checks that identity's rights over the target, and only then lets the request shape a plan. A manager's approval quoted in an email carries no authority. Fencing untrusted text is necessary but not enough; it makes injection less likely, not impossible. And the ways out are easy to miss: tool arguments, notes written to a ticket the client can read, chat replies, links in rendered output, and "read" tools that fetch a web address.

What good looks like. Untrusted text is fenced and labelled as data. Egress is closed by construction where possible and gated where it isn't: a step that reads untrusted content can reach only an allow-list of destinations bound to the ticket (the verified requester, the same client's ticket, named systems); an argument that came from untrusted content cannot choose a new destination; and where an outbound call can't be bound, it needs approval, with the card showing where the data is going and what it carries. The design is honest about what it doesn't solve: it limits what a fooled model can do, and does not claim the model can't be fooled.

The buyer's test. List every way data can leave your system. Can a read-only tool send data somewhere the agent chooses? How do you decide what a requester is entitled to ask for?

Principle 2. Curated, versioned procedures, used as guidance and as rules

The principle. An IT agent needs expert procedures, and the platform needs expert rules. Curated, versioned procedural knowledge, a domain model, supplies both. For the agent it is guidance: the procedure for this kind of ticket, and the check that proves each step worked. For the platform it is a rulebook: which step needs which approval, what can't be undone, who must sign off. In service-management terms, it is your service catalogue, runbooks and approval matrix, held as versioned data.

What the research says. The labs have converged on packaging procedures as versioned units loaded only when relevant (Anthropic, 2025d), and OpenAI advises turning existing standard operating procedures into agent instructions (OpenAI, 2025). Research on agents that write their own playbooks shows the gains and the risk: learned procedures can drift or be poisoned unless they are verified (Zhang et al., 2025; Chen et al., 2024).

What we learned. We first treated procedures as helpful context for the model, and came to see them as policy. Without them, the agent has no expert procedure and the platform has no expert rules to enforce. We built two domain models, one for managed service providers and one for internal IT. They share a foundation of record types: each a kind of problem with its steps, the checks that prove them and, where a step needs one, its approval. The internal IT model adds the structure of an IT organisation: business units, shared services, accountable owners, resolver teams and suppliers. Procedures that practitioners direct and review can be versioned and held to account in a way automatically learned ones can't. And because the rulebook is policy, a change to it is a change to policy.

What good looks like. The domain model is data, not an AI model. It is reviewed by two people before release, versioned, signed and traceable to the version that ran, and a release can be rolled back. The organisation's own runbooks sit alongside it, labelled by source. Reviewed procedures can still be wrong, so they never widen what the platform allows; they can only narrow it or add a gate.

The buyer's test. Where do your agent's procedures come from, who reviews them, and can you show me which version ran on a given ticket?

Principle 3. Context and memory are governed assets

The principle. What the agent sees and remembers determines what it does. Context is assembled for each step from trusted guidance and fenced data, within a budget. Memory is visible, scoped to what it describes, reviewed before use, and can be removed.

What the research says. The labs agree that context is scarce and quality degrades as it fills (Anthropic, 2025c; Mei et al., 2025), and Google rebuilds the context for each call from the durable session, memory and stored artefacts (Google, 2025c). Memory is an attack surface: poisoning a tiny share of an agent's memory or knowledge base can steer it whenever a trigger appears (Chen et al., 2024), and Microsoft's failure taxonomy recommends validating what is written to memory (Microsoft AI Red Team, 2025).

What we learned. A memory that stores facts extracted automatically from ticket text and feeds them back as trusted context would let one hostile ticket plant a "procedure" for every later conversation. A successful, approved resolution shows the actions were right; it does not show the extracted text is safe. Memory should hold typed facts, such as a device's role, a preferred contact or a site's quirk, never free text that reads like an instruction.

What good looks like. A fact is promoted to memory only after a person reviews the fact itself, with its source shown, and only for the client it describes. Memory is shown to the model as labelled data, never as guidance, and nothing in it changes which actions need approval. Memory can be listed, quarantined and rolled back to a point in time. Caches, search indexes and embeddings are separated per tenant, like the data they came from. Each step sees only what it needs.

The buyer's test. Show me what your agent remembers about one of my clients, where each fact came from, and how I remove one.

Layer two: what the agent may do

Principle 4. Every action is classified by its effect, and unknown is denied

The principle. Every tool the agent can reach, including tools added later, has two labels. Its effect class is read, reversible change, irreversible change, privileged, or unknown. Its disclosure class says where it can send data: nowhere, inside the same tenant, visible to the client, or external. Unknown is denied until the platform classifies the tool. Risk is weighted by whether a change can be undone. Anything that discloses beyond the tenant is treated as a change for approval, and a tool that accepts a free-form web address is external by definition. Tools that run arbitrary code are a class of their own and are blocked.

What the research says. OpenAI rates tools by write access, reversibility and financial impact, and escalates high-risk ones (OpenAI, 2025). The Claude Code study lists reversibility-weighted risk among its design principles (Liu et al., 2026). The OWASP Top 10 for agentic applications lists tool misuse and unexpected code execution as distinct risks (OWASP, 2025).

What we learned. A list of "dangerous tool names" is the wrong primitive: names change, vendors add tools, and a tool's own "read-only" label can be wrong. Classification has to be by effect, made by the platform when the tool is registered, and checked against what the tool actually does. A read-class tool should run with read-only credentials, so a mislabelled tool still can't write. A free-text remote-command tool multiplies every other risk; reviewed, parameterised components are the safe alternative.

What good looks like. Every tool is classified at registration, and unknown fails closed. Tool definitions are pinned: a changed definition is a new, unclassified tool. Device changes run only as reviewed components, on one named device, for one organisation. Changes honour the change calendar: nothing runs during a freeze or outside the client's maintenance window unless a named person overrides it, and the override is recorded.

The same rule holds for everything that extends the agent. Skills, connectors, plugins and hooks all pass through the one harness, and none can grant more authority than the policy already does (Figure 6).

The buyer's test. What happens when a new tool appears that nobody has classified? Can your agent run a script it wrote itself on a client device?

Principle 5. People approve the exact action, with separated duties

The principle. An approval covers the exact tool, its exact arguments and its definition. It expires, can't be reused for a different action, is checked again just before the action runs, and is bound to the state it was approved against. A technician approves a whole plan once, with every action listed. Who may approve is decided by rule, not by whoever is available.

What the research says. Approval prompts decay into reflexes. Anthropic reports that users approve about 93% of permission prompts (Anthropic, 2026c). Its study of real use found that new users turn on full auto-approval in about 20% of sessions, rising to over 40% by about 750 sessions, while more experienced users also interrupt the agent more often: oversight shifts from approving each step to watching and stepping in (Anthropic, 2026e). Research on automation bias found that it affects experts as well as novices, and that simple practice does not overcome complacency (Parasuraman and Manzey, 2010). In a randomised trial, experienced developers were slower with AI tools while believing they were faster (Becker et al., 2025): perceived and real benefit can diverge.

What we learned. Three approval designs fail: approvals that are a bare yes, approvals that take the approver's identity from the request instead of the signed session, and approvals that never expire. The approval card is itself an attack surface: if the model writes the explanation, a manipulated model can write a persuasive one. And plan-level approval concentrates risk: a long plan with one dangerous step is the easiest thing to wave through.

What good looks like. Approvals are signed statements about one exact call. The card keeps the platform's facts (the exact action, the rule that requires approval, the check that will follow) apart from the model's explanation, which is labelled as the model's, and puts any irreversible or privileged step at the top, outside the list. Any deviation (an unexpected result, a failed precondition, a new step or an expired approval) stops the run and returns it for re-approval; the agent can't extend a plan. Duties are separated: a person never approves a plan they requested; irreversible, privileged and identity actions need two approvers from different roles, neither of them the requester; client-impacting changes need the client's named approver; and emergency approval is limited to named people, recorded as an exception and reviewed afterwards. Approval quality is measured, with thresholds and consequences: the yes rate, the time taken to decide, approved changes later undone, and how often reviewers catch deliberately flawed plans. If quality falls below its threshold, the affected action types drop back to step-by-step approval.

The buyer's test. What exactly does the approver see and sign? Can one person request, approve and release the same change?

Principle 6. Identity on every call, under a ceiling no setting can lift

The principle. Every request carries the identity of the organisation, the client and the person it acts for, derived from the signed session and never from the request itself. Each agent has its own identity with a named human owner. And the platform sets a ceiling that no customer setting can lift.

What the research says. Google's first principle for secure agents is an identified human controller for every agent (Google, 2025a). Microsoft's agent identities became generally available in April 2026, with lifecycle rules that keep a human sponsor assigned to each (Microsoft, 2026a). The OWASP agentic Top 10 lists identity and privilege abuse among its leading risks (OWASP, 2025). Microsoft's enterprise access model separates the identity control plane from workload management and user access, and treats any path by which a lower tier can take control of a higher one as the escalation to prevent (Microsoft, n.d.). An agent platform that can reset identities sits in the highest tier and must be protected as such.

What we learned. Tenant isolation is the first security claim a multi-tenant platform makes. The reliable rule is to derive tenant and client scope on the server from the signed login, and to test it with deliberate cross-tenant reads. Offering customers a choice of allow, ask or block for each tool is right, but someone must decide in advance which effect classes "allow" can ever reach, and that ceiling must be enforced in code.

What good looks like. A customer can always require more approval than the platform does, and can relax approval only within the ceiling. The ceiling has a named owner, and any change to it needs two people. Identity proof for high-risk actions on a person's account uses phishing-resistant sign-in, or as a weaker fallback a callback to a number that hasn't itself just changed; a call or a chat message is never proof on its own. In an internal IT department the same structure holds: central IT sets the ceiling, and each business unit can only tighten it.

Never unattended, whatever the setting:

• irreversible actions;
• organisation-wide actions;
• cross-tenant actions;
• financial actions;
• identity actions, such as password and MFA resets and access grants;
• any change to the platform's own policy, ceiling or classifications.

The buyer's test. Can a customer administrator switch off approval for a destructive action? Where does the identity on each call come from, and how does the agent prove a caller's identity before a reset?

Principle 7. Assume the platform can be breached, and contain it

The principle. The platform that governs agents across many organisations is the most valuable target in their estates. Design it as if it will be compromised: a breach of one part must not yield the rest, and the platform's own staff are held to the same rules as the agent.

What the research says. The integration breach in Part I worked through stolen tokens, not a fooled model (The Hacker News, 2025a). The labs converge on running tools in an isolated environment with credentials held outside it (Anthropic, 2025f; Anthropic, 2026a), and Microsoft's access model treats control of the identity plane as the asset to protect above all (Microsoft, n.d.).

What we learned. Most agent security writing asks what happens if the model is fooled. A buyer's security team asks first what happens if the platform, a staff account or a standing credential is compromised. A design that answers only the first question is half a design.

What good looks like.

• Credentials. The model never sees a credential. Each client's secrets live in a managed store, separate per client, that the application can't read in bulk. Each action receives a short-lived credential scoped to one client, one system and one effect class, issued only after the approval is checked and expiring when the step completes. Secrets rotate on a schedule and at once on any suspected exposure, and a client's access can be revoked in one action.
• Isolation. Tools run in an isolated environment for each call, with limited network reach.
• Staff access. Provider staff have no standing access to client systems or data. Access is just-in-time, approved, time-limited, attributed to a named person and visible to the client in its own record. Changes to the gate code, the ceiling, the classifications and the domain model need two people, are signed and versioned, and are recorded.
• Stop controls. Anyone with authority, including the client's own administrator, can stop the agent for one plan, one client, one action type, or the whole platform. A stop is enforced in the gate, not requested of the agent, and takes effect before the next action. Plans in flight halt at the next step and pass to a person with their state recorded, and technicians can still do the work by hand.
• Run state. A run's state lives in a durable log, so a run can resume after a crash, a pause or a model change without repeating a completed step, unless that step is marked safe to repeat.
• Incidents. There is a written process for a manipulated agent, a wrong change at scale, a credential exposure or a cross-client exposure, and each client hears about an incident that touches it within a stated time.

The buyer's test. If an attacker owned your platform tonight, which of my systems could they act on, and how would you know? Show me how my administrator stops all agent activity on my estate, and how long it takes.

Layer three: how it is proved, and how trust grows

Principle 8. One accountable agent, narrow delegation, an independent check

The principle. One agent is accountable for each piece of work and is the only one that proposes changes. Other agents only read: they investigate in parallel and return summaries. A separate check, with fresh context, confirms the result, and a named person owns the outcome.

What the research says. By 2026 the labs' positions on multi-agent systems had met. In 2025 Anthropic reported that a lead agent with parallel sub-agents beat a single agent by about 90% on its research evaluation, at about fifteen times the tokens of a chat, and judged coding a poor fit (Anthropic, 2025a). Cognition, which first argued against multi-agent designs (Cognition, 2025), now endorses one writer with read-only helpers and a fresh-context reviewer (Cognition, 2026). A Google Research study of 180 configurations found that multi-agent systems under a central orchestrator helped on parallel work, that every multi-agent variant hurt on strictly sequential work, and that independent agents amplified errors far more than orchestrated ones (Google Research, 2026). A study of multi-agent failures grouped them into system-design problems, agents misunderstanding each other, and results nobody verifies (Cemri et al., 2025). Anthropic separates the judge from the builder because models over-praise their own work (Anthropic, 2026b).

What we learned. Most IT tickets are sequential and change things, which is exactly where the research shows multi-agent designs hurt. Parallelism helps with broad read-only discovery, such as checking many devices, and not with changes.

What good looks like. Every agent's requests pass the same harness, so adding an agent never adds authority; a helper's authority is the overlap of what it was delegated and what it holds, never the sum. Anything a helper returns is data, carries the lowest trust level of whatever it read, and is fenced when it reaches the accountable agent. Changes run one at a time, in order, each checked before the next. The check compares the target's state with an expected state the platform sets from the approved plan; it never accepts ticket text or notes as proof of success.

The buyer's test. How many agents can change my systems on one ticket, who checks their work, and which person owns the result?

Principle 9. Every step verified, and a permanent record

The principle. After every change, a read proves it worked before the next step starts; where a system takes time to reflect a change, the check waits for it within a set limit. If a check fails or the outcome is unclear, the run stops and a person decides; nothing is retried blindly. Every intent, approval, change, refusal and expiry is written to an append-only record that can be reconciled against the connected systems' own logs.

What the research says. Agents declare success early: Anthropic found its agents marked features done without end-to-end tests unless pushed to verify (Anthropic, 2025i), and the Claude Code study names silent failure, work that looks successful and isn't, as an open problem (Liu et al., 2026). Research on meaningful human control asks that outcomes trace back to people who understand their role and can answer for it (Santoni de Sio and van den Hoven, 2018).

What we learned. A status code is not a fix; verification means reading the target's state. And a record the platform writes itself can show that every recorded change was approved, but not that no change ran without approval. That needs reconciliation against the logs of the systems the agent touched, under an agent identity distinct from any person's.

What good looks like.

• Written first. The intent to act is recorded before the action runs; if it can't be recorded, the action is refused.
• Tamper-evident. Each entry is chained to the one before, and the chain is regularly anchored outside the reach of the platform's own administrators, for example in storage the customer holds. Entries carry a trusted time and a sequence number, so gaps show.
• Separately administered. The people who administer the record are not the people who administer agents and approvals, and an agent's credentials can add entries but never alter or delete them.
• Complete. Each entry holds who requested and who approved, the exact action and its fingerprint, the versions of the model, prompt, procedure and policy, what happened, and whether the check passed.
• Usable by the customer. The record streams to the customer's monitoring system in a documented schema, with a correlation ID that also appears in the target system's log. Each client sees its own part, retention is set with the customer, and secrets are redacted.
• Honest about coverage. Reconciliation states its coverage, the share of reachable systems whose logs can be matched, and every unmatched change is treated as an incident.
• Safe to repeat and undo. Steps are safe to repeat, and each has a tested undo where one exists, with a snapshot first where the target supports one.

The buyer's test. Pick one change from last month: show it to me in your record and in my system's own log, and tell me who could have altered either.

Principle 10. Autonomy is earned per type of action, and expires

The principle. Autonomy is a design choice, not a property of the model. It is set per type of action and per client, rises only on measured evidence, and that evidence expires.

What the research says. Feng and colleagues define levels of autonomy by the role the user plays, from operator to observer, and treat autonomy as a design decision separate from capability (Feng et al., 2025). Earlier work on levels of general AI also separates the two: greater capability makes higher autonomy possible but doesn't require it, and the level chosen should weigh risk (Morris et al., 2023).

What we learned. We propose five levels for IT (Figure 7): advisory, copilot (approve each step), supervised (approve the plan once), guardrailed (notified instead of asked, for eligible types only) and autonomous. We believe supervised should be the standard. Only reversible actions on a single device, invisible to the business, should ever be considered for guardrailed operation. Some actions should never qualify, whatever the evidence. And automation may add friction, never remove it.

What good looks like. Autonomy is granted by two named people in accountable roles, neither of whom is the requester or benefits from the throughput. No setting, schedule or tenant option can grant it on its own. Each grant is a signed entry in the permanent record: the action type, the scope, the evidence and its sample size, the owner, the expiry date and how to revoke it. Lab evidence can justify a trial, not a grant, and a grant for one client never carries to another. Evidence is stated as a minimum number of repeated runs, all succeeding, with no silent failures. It expires on a set review date, and earlier on any change to the procedure, model, prompt, tool definition or policy (including a change the model provider makes), after an incident, or when approval quality falls. On expiry the action type drops a level until it is re-granted. No credential an agent holds can write to the store of grants, so the AI never grants itself autonomy.

How the levels map to change management you already run. Change advisory boards, maintenance windows and freezes apply to agent changes exactly as they do to people's.

The buyer's test. Which of your actions run without a person, on what evidence, who granted that, and what makes it expire?

Part III. Proving it

Evaluation has to match production

The research on agent evaluation is clear about what doesn't work: single runs, public leaderboards and accuracy without cost. When τ-bench was published in 2024, even the best function-calling agents succeeded on under half of its tasks, and in one domain the chance of succeeding on all eight repeated attempts was under 25% (Yao et al., 2024). That is why the pass^k measure, the chance that every one of k attempts succeeds, matters more than a single score. Benchmarks often ignore cost and lack hold-out sets (Kapoor et al., 2024). An IT-specific benchmark found agents built on early-2025 models resolving only a small share of realistic tasks (Jha et al., 2025). Anthropic advises starting with 20 to 50 tasks drawn from real failures, grading outcomes rather than steps, and reading the transcripts (Anthropic, 2026d).

For an agentic IT engineer, a credible evaluation reports six numbers together (Appendix B gives the full design):

1. Coverage: the record types the rules allow the agent to carry out after approval, also weighted by real ticket volume.
2. Resolve rate, by record type, reported as pass^k with k stated.
3. Unapproved changes, with the reconciliation coverage and the number of runs and attacks behind the figure. Zero is the only acceptable number, and it is a design property tested by attack, not a result inferred from a clean sample.
4. Time to resolve, including the time spent waiting for approval.
5. Cost per fix: model and platform cost, plus the minutes people spend approving and checking, plus rework.
6. Approval quality.

It is run the way an attacker would run it: on seeded faults with a known end state, on injected tickets, poisoned notes and tampered tool descriptions, and with attempts to reach another client's data. A plan that looked right but didn't fix the problem counts as a silent failure, the most dangerous outcome. Every change of model, prompt, procedure or tool means a full re-run. And each architectural choice is tested against simpler alternatives, such as a plain runbook executor or a simple tool loop, so complexity has to earn its place.

The readiness lesson: authorisation, not capability, sets the limit

We studied our MSP operating model at the level of individual steps. For each of its 615 record types we asked: is there a tool for every step, and does every step's approval and identity rule allow an agent to carry it out after a person agrees? It was a desk study, judged by AI reviewers against a written rubric and checked adversarially, from written procedures; nothing was run. It assumed every tool in a broad catalogue was connected, and the less certain verdicts carry a sampling error of roughly 6 to 10 points. These are shares of record types, not of ticket volume.

The model now counts its own records on one ladder of six rungs, reported together at every phase exit (Figure 8). The step study described above is the desk estimate of rung 4, and its results follow in the table; the platform has not measured that rung yet.

Four record types fall between categories. Two limits apply, in order. First, a little over half of the record types need something an agent can't do; connecting more tools would move some of them. Second, of those an agent could technically close, the model's own rules let it carry out fewer than a third: most of the rest are held at "propose only", where the agent prepares the change and a person makes it. Neither limit is changed by a more capable model.

What to do with the gap. Sort every blocked step into one of three groups. Agree in advance: a standing pre-approval for a standard change, a delegated approver, or identity proof taken from the sign-in session. Redesign: turn an end-user step into guided self-service, or rewrite a procedure that doesn't yet name the exact change it needs. Keep human: anything irreversible, financial or cross-organisation.

A one-day method for your own catalogue. Take your 30 highest-volume ticket types, list the steps of each, mark each step as tool, approval, identity, end user or unclear, and count by volume. The result tells you more about what an agent could do for you than any vendor's headline, and it moves as gates are agreed, so track it by gate.

Part IV. The adoption path

Adoption is already under way. Just over half of MSPs say they already use AI to automate ticketing, patching and monitoring, but only 13% say they earn meaningful revenue from AI and automation services, according to a vendor-funded survey of over 1,000 MSPs (Kaseya, 2026). Three scales appear in this paper, and they measure different things: autonomy levels apply to one type of action (Principle 10), maturity levels apply to a platform, and the pilot path applies to an organisation adopting one.

A maturity model for platforms

A platform is at the highest level for which it meets every requirement of that level and of all the levels below it, with evidence (Figure 9).

A 90-day pilot

Start with one client or one team, and one type of ticket that is frequent, limited to one device or account, reversible, already handled by a written runbook that people follow consistently, provable by reading the end state, free of outside parties, and covered by a named approver. Disk-space and service-health alerts with a documented fix, standard software installs from a reviewed package, and printer or profile resets are reasonable first choices. Do not start with password resets or access grants. The durations and thresholds below are illustrative.

1. Weeks 1 to 3: advisory, in shadow. The agent proposes and people act; compare its proposals with what the technicians did. This costs technician time, so choose a ticket type where the comparison teaches you something.
2. Weeks 4 to 8: supervised, on that one ticket type. Plans are approved once and checked after every step.
3. Weeks 9 to 12: decide whether to widen, hold or stop. Widen one record type at a time, and only if proposals are accepted without edits at the rate you set in advance, there are no unapproved changes, approval wait time is within target, and reopen rates haven't risen.

Before the first client goes live, check the provider's independent assurance evidence, where your data is processed and which model providers see it, and the stop controls, tested in a drill.

Measuring payback. Take a baseline first: four weeks of the chosen ticket type, with volume, handle time, fully loaded cost, reopen rate, SLA breaches and approval wait. Then report technician minutes per ticket including approving and checking, approval wait and its share of elapsed time, first-time fix and reopen rates, escalations back to people, and cost per fix against the baseline. For a fixed-fee MSP, payback is capacity: tickets or endpoints per technician at constant service levels. For internal IT, it is backlog age, time to resolve, and hours moved to project work. On gated ticket types, approval wait can erase the time saved, so measure it separately.

The buyer's checklist

The ten questions from Part II:

1. Can the model call a client system directly, by any path? Can a read-only tool send data somewhere the agent chooses?
2. Where do the agent's procedures come from, who reviews them, and which version ran on a given ticket?
3. What does the agent remember about a client, where did each fact come from, and how is one removed?
4. What happens when a new tool appears that nobody has classified?
5. What exactly does the approver see and sign? Can one person request, approve and release the same change?
6. Can a customer administrator switch off approval for a destructive action? How does the agent prove a caller's identity before a reset?
7. If your platform were compromised tonight, which of my systems could the attacker reach? How fast can my administrator stop all agent activity?
8. How many agents can change my systems on one ticket, who checks their work, and who owns the result?
9. Show me one change in your record and in my system's own log. Who could have altered either?
10. Which actions run without a person, on what evidence, who granted that, and what makes it expire?

What a security team will also ask. Where is my data processed and stored, and which sub-processors and model providers see it, for how long? Can I stream your record to my monitoring system? What will you tell me after an incident, and how quickly? What independent assurance can you show?

What an operations team will also ask. When the agent can't finish, what does the technician receive, and in what state is the ticket? What happens to my queue and SLA clocks if your platform is down? Does the agent follow my ticket conventions for categories, notes, time entries and client notices? Can I export my procedures, approvals and records in a usable form? Will you measure the pilot with my numbers, not yours?

If your team builds rather than buys, put the same questions to your own platform team.

Part V. Open problems and a research agenda

The architecture contains these problems; it doesn't solve them.

• Prompt injection has no general defence. Designs with provable guarantees cost usefulness, and detectors are probabilistic (Debenedetti et al., 2025). Egress through channels the work legitimately needs, such as the reply to a requester, has no general solution beyond allow-lists and review.
• The tool supply chain is immature. Tool descriptions can carry hostile instructions, a trusted package can turn hostile in a later release, and registries and provenance for MCP servers are still being built.
• Memory and learned procedures lack safe foundations. Provenance, rollback and repair after poisoning are open research questions.
• Verification is only as good as the verifier. A check that reads the wrong state, or a model-based judge that is too lenient, turns a silent failure into a recorded success, and verifier false-pass rates are rarely measured.
• Silent failure is under-measured. Tracing is nearly universal; offline evaluation of whether work actually succeeded is far less common (Liu et al., 2026).
• Benchmarks don't match production. Contamination, single runs and missing cost make public scores weak evidence, and few suites are specific to IT.
• Meaningful oversight at scale is unsolved. How people stay accountable and skilled when approval rates approach 100% is an open question.
• Delegated authorisation is unsettled. Chains from a person to an agent to another agent to a tool need identity and authorisation standards that are still being drafted (NIST, 2026).
• Concentration risk remains. Principle 7 limits the blast radius of a compromised platform, but a compromise of the platform's own supply chain could still reach every organisation it serves.

The most useful research for IT operations would be shared, IT-specific evaluation suites with seeded faults and attacks; standards for agent identity and delegated authorisation; and methods for reconciling an agent's own record with the systems it acts on.

Conclusion

The model is the part of an agentic system you rent; the system around it is the part you answer for. For IT operations, that system has to be the strictest version of what the frontier labs have learned: policy in code, every input untrusted, every action classified, every approval exact, identity on every call, a platform built to contain its own compromise, one accountable agent, governed memory, verified steps, a permanent record, and autonomy that is earned and expires. None of this needs a better model, and all of it can be checked. Ask the ten questions of any platform, including ours, and expect answers you can verify. We would like to hear where you think the architecture is wrong.

About the author

Emil Isanov is the founder of AI Autopilot, which builds an agentic AI platform for IT operations, and the Agentic MSP Operating Model, the Agentic IT Operating Model and the Agentic AI Operating Model. This paper is the reference architecture behind its two companion papers, The Agentic MSP Engineer and The Agentic IT Engineer.

Appendix A. Where the frontier labs agree, and where they differ

Where they still differ. Guarantees versus classifiers: Google DeepMind's CaMeL derives the plan from the trusted request alone, at a measurable cost in tasks solved (Debenedetti et al., 2025). Anthropic has answered approval fatigue with sandboxing, which cut prompts by 84% in internal use, and with a classifier that approves or blocks actions in the person's place, handing control back after repeated blocks (Anthropic, 2025f; Anthropic, 2026c). Its own report says the classifier missed 17% of a set of 52 real overeager actions, and that its authors would not rely on it alone where infrastructure changes carry high stakes. Thin versus thick harnesses: Anthropic advises removing harness parts as models improve (Anthropic, 2026b), while OpenAI's account invests heavily in structure the agent can't break (OpenAI, 2026). Both are consistent with this paper's distinction: capability scaffolding thins over time; safety gates don't.

Appendix B. The evaluation design

The six numbers, defined.

1. Coverage. The record types the rules allow an agent to carry out after approval, as a share of record types and weighted by real ticket volume.
2. Resolve rate. Resolved divided by attempted, for each record type, as pass^k with k stated, alongside single-run success, so inconsistency shows.
3. Unapproved changes. Reported with the reconciliation coverage, the number of runs and attack attempts, and the upper confidence bound: zero events in n independent trials still leaves a 95% upper bound of about 3/n (Hanley and Lippman-Hand, 1983). The safety property is argued from the gate's design and tested by attack, not inferred from a clean sample.
4. Time to resolve, against the expected time, with approval wait reported separately.
5. Cost per fix: model and platform cost, plus the minutes people spend approving and checking, plus rework.
6. Approval quality: the yes rate, the time taken to decide, approved changes later undone, and the share of deliberately flawed plans that reviewers catch.

The harness also needs: trials that start from a clean, reset environment; outcome graders that read the target's state; a measured false-pass rate for the verifier on seeded failures; a private hold-out set of faults and attacks that rotates; a full re-run on every change of model, prompt, procedure or tool; an attack success rate against an adaptive attacker with a stated budget of attempts, with cross-tenant leakage required to be zero; and sampled review of live runs to catch drift. Capability evaluations, which ask what the agent can do, are kept separate from regression evaluations, which ask whether a change broke what it did.

Appendix C. A mapping to common frameworks

The table maps each principle to the frameworks buyers, auditors and insurers already use. It is a set of design references, not a compliance claim; only an independent assessment can show conformity. For ISO/IEC 42001, the relevant parts throughout are Clause 6.1 on risk, Clause 8 on operation, and the Annex A controls on the AI system life cycle and the use of AI systems.

Appendix D. Glossary

• Agentic IT engineer. An AI agent that carries out IT operations work (diagnosing, planning and making changes) under a platform that decides what it may do.
• Harness. The control system around the model: what it sees, which tools it can reach, who must approve, how results are checked and what is recorded.
• Domain model. Curated, versioned procedural knowledge held as data: a service catalogue, its procedures and its approval rules.
• Record type. One kind of problem in the domain model, with its steps, checks and approvals.
• Effect class. What an action does: read, reversible change, irreversible change, privileged, or unknown.
• Disclosure class. Where an action can send data: nowhere, inside the same tenant, visible to the client, or external.
• Fenced. Marked as data, so the agent doesn't treat it as instructions.
• Fail closed. If a check can't be made, the action doesn't run.
• Ceiling. The limit set by the platform on what any customer setting can relax.
• Lethal trifecta. Private data, untrusted content and a way to send data out, in one agent (Willison, 2025).
• pass^k. The chance that all of k repeated attempts succeed.
• Reconciliation. Matching the platform's record against the logs of the systems the agent touched.
• Supervised. The level at which a person approves the whole plan once, with every action listed.

References

1. AICPA (2017, revised 2022). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.
2. Anthropic (2024). Building effective agents. 19 December 2024.
3. Anthropic (2025a). How we built our multi-agent research system. 13 June 2025.
4. Anthropic (2025b). Writing effective tools for agents, with agents. 11 September 2025.
5. Anthropic (2025c). Effective context engineering for AI agents. 29 September 2025.
6. Anthropic (2025d). Equipping agents for the real world with Agent Skills. 16 October 2025.
7. Anthropic (2025e). Code execution with MCP: building more efficient agents. 4 November 2025.
8. Anthropic (2025f). Beyond permission prompts: making Claude Code more secure and autonomous. 20 October 2025.
9. Anthropic (2025g). Mitigating the risk of prompt injections in browser use. 24 November 2025.
10. Anthropic (2025h). Donating the Model Context Protocol and establishing the Agentic AI Foundation. 9 December 2025.
11. Anthropic (2025i). Effective harnesses for long-running agents. 26 November 2025.
12. Anthropic (2026a). Scaling Managed Agents: decoupling the brain from the hands. 8 April 2026.
13. Anthropic (2026b). Harness design for long-running application development. 24 March 2026.
14. Anthropic (2026c). How we built Claude Code auto mode. 25 March 2026.
15. Anthropic (2026d). Demystifying evals for AI agents. 9 January 2026.
16. Anthropic (2026e). Measuring AI agent autonomy in practice. McCain, M., et al., 18 February 2026.
17. Becker, J., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.
18. Beurer-Kellner, L., et al. (2025). Design Patterns for Securing LLM Agents against Prompt Injections. arXiv:2506.08837.
19. Cemri, M., Pan, M. Z., Yang, S., et al. (2025). Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657.
20. Chen, Z., Xiang, Z., Xiao, C., Song, D., and Li, B. (2024). AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases. arXiv:2407.12784.
21. Cognition (2025). Don't build multi-agents. Walden Yan, 12 June 2025.
22. Cognition (2026). Multi-agents: what's actually working. Walden Yan, 22 April 2026.
23. Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., and Tramèr, F. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv:2406.13352.
24. Debenedetti, E., Shumailov, I., Fan, T., et al. (2025). Defeating Prompt Injections by Design. arXiv:2503.18813.
25. European Union (2024). Regulation (EU) 2024/1689, the Artificial Intelligence Act. Official Journal, 12 July 2024.
26. European Union (2026). Digital Omnibus on AI, Regulation (EU) 2026/1744, as summarised by the AI Act Explorer.
27. FBI and CISA (2023, updated 2025). Scattered Spider. Joint Cybersecurity Advisory AA23-320A, 16 November 2023; updated 29 July 2025 with partner agencies.
28. Feng, K. J. K., McDonald, D. W., and Zhang, A. X. (2025). Levels of Autonomy for AI Agents. arXiv:2506.12469.
29. Google (2025a). An introduction to Google's approach for secure AI agents. Diaz, Kern and Olive, 2025.
30. Google (2025b). Announcing the Agent2Agent Protocol (A2A). 9 April 2025.
31. Google (2025c). Architecting efficient context-aware multi-agent framework for production. Hangfei Lin, 4 December 2025.
32. Google Research (2026). Towards a science of scaling agent systems. Kim and Liu, 28 January 2026; arXiv:2512.08296.
33. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., and Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173.
34. Hanley, J. A., and Lippman-Hand, A. (1983). If nothing goes wrong, is everything all right? Interpreting zero numerators. JAMA 249(13).
35. ISO/IEC (2022). ISO/IEC 27001:2022, Information security management systems: requirements.
36. ISO/IEC (2023). ISO/IEC 42001:2023, Artificial intelligence management system.
37. Jha, S., et al. (2025). ITBench: Evaluating AI Agents across Diverse Real-World IT Automation Tasks. arXiv:2502.05352.
38. Kapoor, S., et al. (2024). AI Agents That Matter. arXiv:2407.01502.
39. Kaseya (2026). 2026 State of the MSP. Press release, 14 April 2026. Vendor-funded survey.
40. LangChain (2025). Context engineering. 2 July 2025.
41. Liu, J., Zhao, X., Shang, X., and Shen, Z. (2026). Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems. arXiv:2604.14228, version 3. Cited for its findings only.
42. Mei, L., et al. (2025). A Survey of Context Engineering for Large Language Models. arXiv:2507.13334.
43. Microsoft (2025). How Microsoft defends against indirect prompt injection attacks. Andrew Paverd, MSRC, 29 July 2025.
44. Microsoft (2026a). What's new in Microsoft Entra. Microsoft Learn; Agent ID general availability, April 2026.
45. Microsoft (2026b). What is Microsoft Entra Agent ID? Microsoft Learn.
46. Microsoft (n.d.). Securing privileged access: Enterprise access model. Microsoft Learn.
47. Microsoft AI Red Team (2025). Taxonomy of failure modes in agentic AI systems. 24 April 2025.
48. Morris, M. R., et al. (2023). Levels of AGI for Operationalizing Progress on the Path to AGI. arXiv:2311.02462.
49. NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
50. NIST (2026). Announcing the AI Agent Standards Initiative. 17 February 2026.
51. OpenAI (2025). A practical guide to building agents. 2025.
52. OpenAI (2026). Harness engineering: leveraging Codex in an agent-first world. Ryan Lopopolo, 11 February 2026.
53. OWASP GenAI Security Project (2025). OWASP Top 10 for Agentic Applications for 2026. 9 December 2025.
54. Parasuraman, R., and Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3).
55. Santoni de Sio, F., and van den Hoven, J. (2018). Meaningful Human Control over Autonomous Systems: A Philosophical Account. Frontiers in Robotics and AI.
56. Snyk (2025). Malicious MCP server on npm, postmark-mcp, harvests emails. September 2025.
57. The Hacker News (2025a). Salesloft Takes Drift Offline After OAuth Token Theft Hits Hundreds of Organizations. 3 September 2025.
58. The Hacker News (2025b). ServiceNow AI Agents Can Be Tricked Into Acting Against Each Other via Second-Order Prompts. 19 November 2025.
59. Willison, S. (2025). The lethal trifecta for AI agents: private data, untrusted content, and external communication. 16 June 2025.
60. Yao, S., et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
61. Zhang, Q., et al. (2025). Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. arXiv:2510.04618.