When the Intern Deploys an Agent on Day One

The intern arrives on a Monday. By Tuesday afternoon she has wired up her first agent. By Wednesday morning that agent has invoked a production tool through a credential she should not have inherited, and nobody on the security team knows it happened because the audit trail records the call as coming from "the intern's senior mentor's setup script" — which is technically true and operationally useless.

This is not a story about a bad intern or a careless mentor. It is a story about an onboarding pipeline that has decades of refinement behind its assumptions about new humans — read-only first, sandboxed write next, production after a tenure threshold — and zero refinement behind its assumptions about the agents those humans configure on day one. The IAM model for humans is no longer the IAM model for what gets executed against your systems, and most security teams have not noticed yet.

The Pipeline That Was Built for Humans

Walk through what a competent engineering org gives a new hire on day one. There is a laptop with a managed image. There is commit access to one repository, scoped by the team they joined. There is read-only access to production logs, gated behind a VPN and a hardware key. There is a Slack handle, an email, a calendar, and a row in the directory that maps their employee ID to a role with a calibrated permission set. The role itself was negotiated quarters ago between security, engineering leadership, and IT. Every grant in it has a story.

That pipeline is the product of a long, expensive conversation about blast radius. The reason a new hire cannot push directly to main is not that they are untrusted as a person; it is that the cost of a mistake by an inexperienced operator against production is asymmetric. The seniority gradient — read, then sandboxed write, then production after a probation — is a risk-amortization curve. It exists because somebody, years ago, watched a new hire accidentally drop a table and decided this was a category of incident the org would design out rather than apologize for.

Now consider what that same intern's first task actually looks like in 2026. She is told to ship a small feature that uses the team's agent framework. To do that, she needs an entry in the tool registry so her agent can be discovered. She needs a system-prompt PR merged into the team's prompt monorepo. She needs a seat on the eval set so her agent's outputs run against the team's regression suite. She needs a sandboxed credential to call the staging API. She needs a chargeback bucket so the inference spend rolls up to a budget owner. And every one of those handoffs sits in a runbook that was written for a senior engineer — because until last quarter, only senior engineers were doing agent work.

The intern does what any reasonable person would do. She finds the senior engineer's setup script in a Confluence page, copies it, runs it, and her agent starts working. The script provisions the credentials it knows how to provision. It does not know she is an intern. It does not know the staging credential it grants also grants read access to a production-adjacent queue because somebody six months ago took a shortcut. It does not know that the tool registry entry it creates is approved by default because the registry's review gate was written when the only humans creating entries were team leads.

Why Agent Provisioning Is a Different Surface

A human IAM model assumes the human is the unit of action. Grant the human permissions, log what the human does, revoke when the human leaves. The whole model rests on a stable identity that you can negotiate with, audit, and ultimately fire.

An agent breaks every one of those assumptions. The agent is configured by a human but acts independently. Its permissions are not the human's permissions — they are a separate capability bundle that the human assembled, often by copying somebody else's bundle without reading the full list. The agent's actions are logged, but the logs say the agent did them, not the human who shaped the prompt, not the engineer who added the tool, not the reviewer who approved the registry entry. When the agent makes a bad call, there is no single throat to grab.

This is the surface area that traditional security review does not cover. Security review owns human IAM. The AI team owns the tool registry. The platform team owns the credential vault. The finance team owns the chargeback. And the intersection — the place where a junior engineer can compose a hazardous capability bundle out of individually approved pieces — has no owner. It is the seam between functions, and seams are where incidents live.

A useful frame: the agent is not a tool the engineer uses. It is an employee the engineer hires. And right now your org has no HR process for the employees your interns are hiring on day three.

The Seniority-Aware Capability Bundle

The discipline that has to land borrows directly from the human onboarding playbook. New humans get a read-only-first permission set, calibrated to their role and tenure. New agents — or rather, the configurations of agents created by people at a given seniority — need the same gradient.

Concretely, this means a per-role agent capability bundle. An intern can configure an agent that calls read-only tools, queries documentation, drafts pull requests for human review, and runs against a fully sandboxed staging environment. A mid-level engineer can additionally configure agents that write to development databases, call internal services with traced credentials, and submit to the eval set without two-person review. A senior engineer can configure agents that touch production-adjacent surfaces, but only with an approver named in the registry entry. A staff engineer or above can configure agents that operate against production, with a documented blast radius and a kill condition.

The model is not "what can this person do" but "what can the agent this person configures do." Those are different questions and they need separate answers. A junior engineer is fully trusted to write code that goes through code review before it touches production; the same junior engineer should not be implicitly trusted to configure an agent that is the production touch, because the review gate that exists for code has no equivalent for prompts and tool grants.

The default posture has to be deny. Every additive grant in the tool registry needs an approver who can name the blast radius in plain English. If the approver cannot describe what breaks when this tool is misused, the tool is not ready to be in the registry. This is the same discipline that produced the modern code review culture — somebody had to be able to articulate why a change was safe — applied to a new artifact class.

The Audit Trail That Distinguishes Author From Caller

The other discipline that has to land is provenance in the audit trail. When the intern's agent invokes a production tool, the log entry has to record at least four facts: the human principal whose authority is being exercised, the prompt author, the tool grantor, and the agent runtime. Right now most observability stacks record one or two of those at best, usually the runtime and maybe a delegated identity. The rest is lost in the seam.

Without that four-way record, incident response is forensic guesswork. With it, the question "who is accountable for this action" has an actual answer, and the answer can be different for different parts of the action. The prompt author may be the intern. The tool grantor may be the senior engineer whose script she copied. The principal authorizing production access may be a team lead who signed off on the registry entry three weeks ago without reading it carefully. Each of those people has a different relationship to the failure, and each one needs to learn something different from it.

The 2026 numbers make the case loudly. Non-human identities now outnumber human identities by ratios from 40:1 to 500:1 in heavily automated orgs. A majority of organizations report that those identities are not consistently governed under privileged access policies. A majority of security incidents now involve machine identities. The audit trail problem is not theoretical — it is the daily reality of a team trying to determine why a credential they thought was sandboxed showed up in a production log this morning.

The architectural realization is that the agent's identity has to be a first-class principal in the IAM system, distinct from the human who configured it and the human whose authority it currently exercises. Treating the agent as a thin wrapper around a human identity is what produced the audit-trail collapse in the first place. The agent gets its own row in the directory, its own credentials with cryptographic attestation, its own permission set negotiated against a capability bundle, and its own lifecycle that does not automatically inherit from the human who created it.

What the Fresh-Hire AI Onboarding Module Looks Like

The piece that has to land before the first commit is an onboarding module that covers the agent-permission model the same way the security training module covers data classification. Right now most onboarding modules treat AI as a product the company sells or uses. Almost none treat it as a capability the new hire will personally configure within their first week.

The module needs to cover, at a minimum: what the tool registry is and what it means to add an entry; what the difference is between a prompt and a capability and why each requires a different review; what the default-deny posture means in practice and how to request additive grants; what the chargeback model is and how to estimate spend before launching; what the audit trail will show when the agent runs and how to read it; and what the kill conditions are for an agent that misbehaves. None of this is more complex than the data-handling training every new hire already sits through. It is just new, and no team has been given the budget to write it.

The political surface here is real. Adding a gate before the first agent ships looks like slowing the team down. The counter-evidence is the slow accumulation of incidents — the credential that should not have leaked, the production tool that should not have been called, the inference bill that should not have grown — each one individually explainable, collectively a pattern that points at a missing layer of the org chart. The onboarding module is the cheap, repeatable intervention that makes the missing layer visible to every new hire on their first day, before they need to learn it the expensive way.

The day a new hire's productivity comes from agents they configure rather than code they write, the IAM model for humans stops being sufficient. The orgs that recognize this early build a second onboarding pipeline alongside the first one — one for the human, one for the agents the human will create — and treat them with comparable seriousness. The orgs that recognize it late spend a quarter reconstructing what an intern's agent did in week one, and then write the pipeline anyway, after the incident.