Why AI Should Be Treated Like an Employee

An agent that can act on your systems needs what a member of staff needs: an identity, a job description, scoped permissions, a supervisor, an audit trail, a review and a way to be removed. Agentic AI feels ungovernable not because governance has yet to be invented, but because we are not applying what we already have, refined over generations of employment law and internal audit, to the newest class of worker on the network.

Most organisations onboard a temporary contractor with more rigour than an agent holding write access to a finance system. The contractor gets a reference check, a named manager, a written scope of work, a badge with defined access, probation and an exit process. The agent gets an API key.

What does an employer actually do that nobody does for an agent?

Employment is not a sentimental arrangement. It is a control system built to answer one hard question: how do you let an actor with discretion operate inside your perimeter, on your data, in your name, without losing control of the outcome? Identity, written scope, permission matched to role, supervision, records, review, a clean exit. Each of those exists because an organisation once learned the cost of not having it.

An agent's day one: a credential, a system prompt and production access. No named owner. No written scope that anyone in risk has read. No probation, no review date, no revocation procedure beyond someone remembering the key exists. If a human joined on those terms, the audit committee would call it a material control failure. When it is an agent, it is called a pilot.

Isn't an agent just a service account that speaks English?

This is the strongest objection and it deserves a straight answer. Non-human identity is a real discipline: service accounts have identifiers, scoped credentials, rotation schedules and revocation.

The distinction is discretion. A service account executes a fixed instruction set, so its permissions and its behaviour are effectively the same object: know one and you can predict the other. With an agent they come apart. You grant a capability, and the agent chooses the act, the sequence, the timing and the target within it. That gap between what an actor may do and what it will do is the gap employment was built to manage in people. We do not govern staff by enumerating permitted keystrokes, because we cannot. We scope the role, supervise the work, keep the record and review the outcome. Agentic AI is discretion sold as a feature, so permission engineering alone stops being sufficient.

Where does the employment analogy break down?

In three places. Deterrence: employees behave partly because they have skin in the game, a career, the prospect of dismissal, and none of that transfers to an actor that cannot be sanctioned or shamed. Speed: human error is bounded by the hours in a day, while an agent can repeat the same mistake at machine speed, and at machine volume, before the first exception report renders. Tacit context: staff absorb unwritten judgement about what would embarrass the firm, and an agent has the written policy and nothing else. Each failure argues for more mechanical control, not less: an actor that cannot be deterred must be constrained and evidenced at the moment it acts.

What would proper onboarding for an agent look like?

It looks like human onboarding, because the problem is the same shape. Before production access:

• Identity: one attributable identity per agent. Never a shared key, never a borrowed credential.
• Job description: a written scope, what is in, what is out, which systems it may touch.
• Clearance: permissions granted per action against that scope, not a role bundle copied for convenience.
• Probation: consequential actions approved by a named human before execution, not after.
• Supervision: thresholds to stop and escalate, set in money, data class and irreversibility.
• Record: every consequential action sealed before it executes, not logged after it succeeds.
• Review: competence tested against outcomes by someone with authority to reduce scope.
• Offboarding: revocation tested, dated and evidenced, covering credentials and cached context.

Who is the agent's line manager?

A named person, on the record, before deployment. An agent with no owner is the equivalent of a member of staff nobody remembers hiring: present, active, credentialled, belonging to no one. That is how orphaned automation survives reorganisations, keeps its permissions for years and appears in an incident review as a surprise. Ownership settles the question boards keep trying to route around. Under GDPR Article 22, the rights of a data subject facing an automated decision run against the controller, not the model and not the vendor.

Why does the record matter more than the policy?

A policy is a claim about behaviour and a record is evidence of it, and only one survives contact with a regulator or a court. Every organisation deploying agents has a policy. Very few can prove, months later, what a specific agent did on a given day, on whose authority, under what constraint, and that the account has not been edited since.

What matters is when the record is made. A log written after the fact, by the system that performed the act, is that system's testimony about itself: incomplete, retrospective, rewritable. Mickai seals every consequential action before it executes, signs the seal with post-quantum FIPS 204 ML-DSA-65 and hash chains it into an Open Audit Record a regulator or a court can verify offline. Supervision is only real if the supervisor can check the work and the worker cannot rewrite the timesheet.

Frequently asked questions

Does treating an AI agent like an employee mean giving it legal rights?

No. The analogy runs one way. Employment is a control model, not a status: identity, scope, supervision, records, review and revocation are internal disciplines, and none implies personhood or legal agency. The agent is not a colleague. It is an autonomous actor inside the perimeter, the category those controls were built for.

Is a tightly scoped service account enough for an agent?

No, because permissions govern capability and agents exercise discretion within capability. A scoped service account behaves predictably, so its permissions are a fair proxy for its actions. An agent's are not. You still need escalation thresholds, a contemporaneous record and a review cycle. Permissions tell you what an agent could do; only the record tells you what it did.

Who is accountable when an agent makes a costly mistake?

The organisation, and within it the named human owner of that agent. Accountability does not transfer to a model, and in most commercial arrangements not to a vendor either. Where automated decisions affect people, GDPR Article 22 places the obligation on the controller. Assign ownership before deployment, rather than reconstructing it after the incident.

What is the first step for a board that already has agents in production?

One inventory. List every agent able to act on production systems, with its owner, its written scope, its permissions and its tested revocation procedure. Most organisations find the list is longer than expected and the columns are mostly empty. That document makes the argument better than any policy paper.

Mickai is a British Sovereign Intelligence Operating System, built and live, running offline on hardware the organisation owns, in its own jurisdiction. It treats every agent as a member of staff: clearance per action, a gated sandbox it cannot reach outside, a named accountable owner, and an Open Audit Record that seals each consequential action before it executes and can be verified offline by a regulator or a court. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, held by Mickai LTD. The design is at /sovereign-ai, the audit model at /oar, and if you do not know how many agents are acting on your systems, start at /ai-readiness.