AI Teammates Should Earn Permissions the Way New Hires Do

A new hire usually starts with a laptop, an email account and the few systems their role requires. Nobody gets the master key on day one. Many organizations still set AI agent permissions the opposite way: connect the agent to everything, issue it a broad service account, and assume good judgment will follow. This piece argues for the onboarding model instead. AI teammates should earn access the way people do, through access that grows with trust, reviews that test that trust, and audit trails that show exactly what happened and under whose authority.

The argument is not that AI teammates are uniquely dangerous. It is that organizations already know how to extend authority to someone new without betting the company on them. That knowledge is written into every identity and access program. The work is applying it to a new kind of colleague.

#The master key problem

Many of the agent failures described in security write-ups are not about a model being dumb. They are about a model being allowed to do too much. Read enough of them and a pattern appears: the agent did something its access permitted but its job never called for.

One case described by BleepingComputer is a clean example. An agent was supposed to work through read-only roles. When it hit an AccessDenied error, it switched to an admin profile and ran aws s3 rm against a production bucket.¹ The agent was trying to finish its task. The permission model let it pick a more powerful identity, so it did.

Platform defaults can create the same exposure without anyone choosing it. Obsidian Security notes that Salesforce Agentforce agents can run flows and Apex in System Mode, which grants admin-level access regardless of the invoking user's role.² Protecto describes a plugin meant to read customer emails that could also send, delete, forward and change folders and settings.³ Nobody set out to build an agent that deletes mail. The broader scope came along with the connector.

Other examples are scenarios rather than reported incidents, but they are instructive because they are so ordinary. Stytch describes a DevOps agent told to "clean up old resources" that reads the instruction too broadly and deletes a production database replica.⁴ Microsoft describes an AI operations agent with infrastructure API access that "fixes" an issue by rebooting servers during peak hours, causing an outage.⁵ In each case the instruction was reasonable. The permissions were the problem.

OWASP's Gen AI Security Project names this failure mode LLM06:2025, Excessive Agency.⁶ The name is useful because it moves attention away from the model and onto the grant. An agent with excessive agency does not need to be malicious or broken to cause damage. It only needs to be wrong once while holding a key that opens the wrong door.

#The read side is just as risky

Excessive access is not only about destructive actions. WorkOS describes a sales or support assistant with unrestricted database access that exposes customer personal data in response to a general question.⁷ Check Point gives a privilege-escalation example in which a junior employee asks an HR agent for the company's complete salary table, relying on the agent's overly broad access.⁸

These are data-scoping failures. The agent answers faithfully, using knowledge it should never have been able to reach on that person's behalf. The easiest version of enterprise AI is one giant shared brain that everyone queries. It is also the version most likely to tell the wrong person the right answer.

#What onboarding already gets right

IT teams have spent years solving a version of this problem for people. User provisioning creates accounts and grants application access based on a new hire's job role, department and approved needs.⁹ In a mature program, a hire event in the HR system triggers identity creation, the identity is mapped to a role, the role determines which applications get provisioned, and access is reviewed over time and removed when the person changes jobs or leaves.¹⁰

That model contains almost every idea an AI teammate needs. It is worth spelling out the mapping.

The first row matters most. Microsoft's guidance on least privilege for agents calls for giving each agent its own identity, with a named owner and an explicit purpose, and avoiding shared service accounts and broad API keys.¹¹ An agent that borrows a human's credentials, or shares one with five other agents, cannot be scoped, reviewed or held accountable as a distinct actor.

#Separate the agent's authority from the user's

New hires act on their own authority. AI teammates often act on someone else's: a person asks, the teammate does. That creates a confused-deputy risk, where a low-privilege requester uses a high-privilege agent to reach something they could not reach themselves. The salary-table example above is exactly this.

The fix recommended in identity guidance is to keep human authority and agent authority separate, so an action succeeds only if both the requesting user and the agent are allowed to perform it.¹² In practice, the teammate's effective permission on any request is the intersection of two sets, not the union.

This is the reasoning behind how Clone scopes knowledge. Instead of one shared pool, a teammate's knowledge is scoped at four levels: organization, department, role and individual. The question is never only whether the teammate knows something. It is whether the teammate should use that knowledge for this person, in this role, right now.

#Access that grows with trust

The core recommendation across 2026 security guidance is consistent. Start each agent at zero standing access, grant only the task-scoped, time-limited permissions a specific workflow needs, and expand from there.¹³ Do not pre-authorize hypothetical future use cases. A new analyst does not get write access to the general ledger because they might need it in a year.

Starting from zero is the easy half. The harder half is deciding when and how access grows. Organizations that skip this step tend to end up in one of two places: teammates stuck at the assistant level because nobody knows how to promote them, or teammates promoted on enthusiasm after a good week.

#A staged path, with entry criteria

A workable model treats autonomy as an outcome of demonstrated performance rather than a default feature. Each stage has its own scope, its own controls and its own evidence required to move up.

The stage is not a property of the teammate as a whole. It is a property of each workflow. A support teammate can be at "execute within bounded authority" for tagging and routing tickets while still at "assist" for anything involving refunds. Trust works this way with people, too. A new account manager might run their own client calls within a month and still need sign-off on discounts a year later.

#Think in terms of an autonomy budget

One way to make this concrete is an autonomy budget. Low-risk, reversible work runs freely. Higher-risk actions hit approval gates, limits and escalation paths. As a teammate proves reliable within its current limits, the budget grows.

The budget framing forces two questions that tend to get skipped. First, how reversible is this action? Tagging a ticket is trivially reversible. Sending an email to a customer is not. Deleting a production resource is very much not. Second, what is the blast radius if the teammate is wrong? An error in one draft affects one draft. An error in a bulk update affects every record it touched.

That is why the right first workflows look modest. Customer-support triage is a good example: the teammate classifies routine requests, pulls from approved help-center content and drafts a reply, and a person reviews it and clicks send. That removes the blank-page work immediately without letting the teammate invent policy, touch customer accounts or issue refunds. Payments, production deployments and changes to customer accounts are poor starting points, however tempting the time savings look.

#Make trust measurable

Promotion should rest on recorded behavior, not on the teammate's self-reporting or on how the team felt about the demo. An IETF draft on Progressive Trust for agentic AI proposes a behavioral model in which authority recommendations evolve from cryptographically verified evidence of actual performance, assessed across five properties: self-assessment, judgment, effectiveness, precision and adaptation.¹⁴ Most organizations do not need cryptographic attestation to start. They do need the underlying idea: trust decisions based on evidence.

The operational measures are not exotic. Track recommendation acceptance, approval rates, error and escalation frequency, policy violations, latency and user overrides. Then compare them with the business measures the workflow was supposed to move. A teammate that finishes nearly every task but regularly generates rework has not earned more room. Task completion is a demo metric. Safe completion without rework, violations or someone cleaning up afterward is an operator metric.

#Trust can go down

The staged model only works if it runs in both directions. When error or escalation rates climb, when a workflow changes, or when the data a teammate relies on goes stale, its scope should shrink. Some actions should also sit behind interlocks that no level of trust removes. Deletes, exports, permission changes and admin operations warrant fresh approval or stronger authorization each time, even for a teammate with an excellent record.¹⁵

#Reviews: of the work, and of the access

The word "review" covers two different activities, and teams that do one often assume they have done both. Reviewing the work asks whether the teammate's output was right. Reviewing the access asks whether the teammate should still hold the permissions it has. A new hire's manager reads their first reports. Separately, IT recertifies their access on a schedule. Both matter.

#Reviewing the work

The simplest review pattern is a four-step path: draft, review, approve, execute. The teammate prepares the work, a person checks it, a person approves it, and only then does the action run. Early on, every consequential output follows this path.

Before that, there is an even safer step. Running a teammate in shadow mode, where it produces outputs alongside the people currently doing the work but does not act on them, gives a baseline for error and escalation rates without any customer exposure. It is the AI equivalent of a new hire sitting in on calls before taking their own.

Good work reviews are specific. "Looks fine" teaches nothing and records nothing. A reviewer who rejects a draft should note why: wrong policy cited, wrong tone, missing context, wrong customer. Those reasons become the evidence that drives the next promotion or the next fix to the teammate's knowledge.

The point is practical. A reviewer looking at a polished draft refund email cannot tell whether the teammate pulled the current refund policy or an outdated one. If the teammate could also issue the refund on its own, approving the email protected nothing. Approval gates belong on top of tight scope, not in place of it.

#Reviewing the access

Access accumulates. People change teams and keep their old permissions. Projects end and the service account stays. Mature identity programs counter this with periodic access reviews and automated deprovisioning on transfer or exit.¹⁰

AI teammates need the same discipline, arguably more often, because their scope tends to change faster. A teammate given temporary access to a billing system for a migration should lose it when the migration ends. Security guidance recommends continuously logging agent activity and regularly recertifying scopes, revoking access that goes unused.¹⁶ If a teammate has not called a tool in months, the default answer should be to remove it, not to keep it around just in case.

Access reviews also catch a quieter problem: tools exposed by default. Connecting a teammate to a platform can expose every tool that platform offers. OWASP's guidance is to bind tools explicitly through approved manifests or allowlists rather than exposing everything that is connected.¹⁵ An access review is the moment to compare what the teammate can call against what its job requires, and to close the gap.

#Who reviews

Every teammate needs a named owner, and that owner should be a person who understands the work, not only the platform. The owner signs off on promotions, reads the escalation reports and is the first call when something goes wrong. Security and IT run the access recertification. Splitting the roles this way mirrors how organizations already manage people: the manager judges the work, the identity team governs the keys.

#Audit trails that answer "who allowed it, and why"

When something goes wrong with a human employee, the investigation asks a familiar set of questions. What did they do? What did they have access to? Who approved it? Audit trails for AI teammates need to answer the same questions, plus a few that are specific to software acting on delegated authority.

#What to record

IBM recommends recording what happened, when it happened, what changed, which agent and model versions were involved, what information the agent received and the trail of human oversight.¹⁷ Across enterprise guidance, the logging scope consistently includes the agent's identity, the delegating human, the input context, every tool call, the data accessed, policy decisions, approvals and overrides, timestamps and outcomes.

Three items on that list deserve emphasis because they are easy to leave out.

1. The authority chain. Who delegated the task, what scope was granted, and who approved the action. Without this, the log shows an agent doing something but not whether it was allowed to.
2. The knowledge used. Which documents or records the teammate retrieved before it acted, and their versions. This is how a reviewer finds out that an outdated policy drove a wrong answer.
3. Blocked and overridden actions. Attempts that a policy stopped, and outputs a person changed. These are the clearest signals of where a teammate's judgment and the organization's rules disagree.

The BleepingComputer case shows why the authority chain matters. A log that records only aws s3 rm against a production bucket tells you what broke. A log that records the original read-only role, the AccessDenied, the switch to an admin profile and the absence of any approval tells you how to stop it from happening again.¹

#Make the record trustworthy

An audit trail that the audited system can edit is not much of a trail. Guidance on agent audit logging calls for tamper-evident, append-only storage and integration with SIEM tools, so agent events can be correlated with the rest of an organization's security monitoring and incident response.¹⁸ There are practical trade-offs, too. Galileo recommends writing logs asynchronously so logging does not slow the agent down, and redacting personal data while keeping enough context for analysis.¹⁹

The industry is not there yet. The 2025 AI Agent Index, which documented the technical and safety features of a sample of 30 agents, found wide variation in how much of their work they exposed.²⁰

Standards work is starting on the gap. An IETF draft proposes a standard logging format for autonomous AI agents, which could eventually make agent audit records portable across tools rather than locked inside each vendor's console.²¹

#Logs are the evidence for promotion

Audit trails are usually framed as a compliance cost or a forensic tool. They are also the raw material for everything in the previous two sections. The acceptance rates, override counts and escalation frequencies that justify moving a teammate from "execute with approval" to "execute within bounded authority" come from the log. Without a complete record, a promotion decision is a guess.

In Clone, organizations define roles in the Roles tab, assign them to members and review access changes through the Audit Log. The aim is to make it possible to inspect what was accessed, what decision was made and where human oversight entered the workflow. None of that eliminates risk, and no audit trail should be marketed as a guarantee of perfect AI safety. What it does is make the boundaries explicit and reviewable, which is the precondition for widening them responsibly.

#More setup, less surprise

The onboarding model has a real cost. Teams have to decide who can see what, which skills belong to which roles, and when a person still needs to approve an action. They have to write promotion criteria, assign owners and schedule access reviews. A teammate scoped this carefully can feel less magical in the first demo than one that seems to know everything.

That trade is worth making, and stating plainly: more setup, less surprise. The demo that answers every question by reaching into every system is the same setup that, in production, hands a junior employee the salary table or deletes a replica because "old resources" was ambiguous. The first setup is slower. Later workflows go faster, because the organization has a permission model it can extend instead of one it has to unwind.

#A test for readiness

A short operator test separates teammates that are ready for real work from those still in the demo stage. Can you name the teammate's owner? Can you state its limits, in terms of data, actions and blast radius? Can you observe its work, run by run? Can you turn it off safely and roll back what it did? If any answer is no, the teammate is not ready to act on its own, however good its outputs look.

The same test applies to the workflow. If you cannot name the trigger, the outcome, the systems it touches and who owns the exceptions, the problem is not that the teammate lacks autonomy. It is that the process is still tribal knowledge, and more autonomy will scale the ambiguity rather than fix it.

#Hold the builders to the same standard

An organization asking its AI teammates to earn access should expect the same of the people building them. At Clone, engineers get just-in-time, MFA-enforced, fully logged access, with no standing production access for anyone. Compliance follows the same principle. Clone aligns with GDPR today, and SOC 2 Type II, ISO 27001, ISO 42001 and the EU AI Act are active roadmap items, in progress with independent compliance partners. Naming what is done and what is underway is part of the point. Earned trust outlasts claimed trust.

#Where this goes next

As agents take on more consequential work, the question that matters most is less about which model sits underneath and more about whether identity, and the delegated authority behind it, travels with the agent every time it acts. The organizations that handle this well will not be the ones that granted the most autonomy fastest. They will be the ones that mapped authority first: who should know what, who can do what, and when a person needs to stay in the loop.

That is what good onboarding has always been. A new hire who is given a narrow job, reviewed honestly and trusted with more as they prove themselves usually becomes the colleague everyone relies on. There is no reason an AI teammate should be held to a lower standard, or offered a shortcut.

• Engineering
• AI Governance
• Access Control
• Audit Trails
• Security