Your AI agent needs an onboarding process. Here's why

AI Dev Tools — General
, ,
1

Your AI Agent Needs an Onboarding Process. Here’s Why.

AI_Prohibited
AI_Prohibited1024Ă—1024 154 KB

You wouldn’t give root access to production to a new employee on their first day. No admin credentials, no unrestricted access to all internal systems, no ability to send emails on behalf of the company without someone reviewing them first.

Yet that’s exactly what most devs do when they spin up an AI agent.

This week, both Microsoft and IBM published analyses on AI agents entering the workplace as “digital coworkers.” Both reached the same uncomfortable conclusion: the security model for AI agents, in most teams, basically doesn’t exist.

The “digital coworker” framing isn’t metaphor — it’s policy

Vasu Jakkal, VP of Security at Microsoft, said it plainly: every agent should have the same security protections as a human employee. That means a clear identity, scoped access (only to what it actually needs), a record of everything it creates or touches, and protection against external attackers trying to manipulate it.

That last point deserves attention. AI agents operating in codebases, reading files, executing terminal commands, and calling external APIs are increasingly attractive targets for prompt injection attacks — where malicious content in files or web pages tries to hijack the agent’s behavior. If your agent can read a README and execute code, a carefully crafted README can make it do things you never authorized.

IBM’s analysis goes even further. Shlomi Yanai from AuthMind frames it as a slow-motion governance crisis: in a few years, non-human identities (AI agents, automated workflows, service accounts) will outnumber human users in most organizations. The question isn’t whether you have AI agents running — you probably already do. The question is whether anyone can answer three things about each one:

  1. Do you know it exists? Is it cataloged somewhere?
  2. Do you know what it’s accessing? Files, APIs, databases?
  3. Do you trust what it does when it gets there? What can it read, write, delete, or call?

If you can’t answer all three, you’re not running an agent — you’re running a blind spot.

This isn’t just an enterprise problem

It’s easy to read “Microsoft and IBM talking about AI governance” and mentally file it under “enterprise IT concerns that don’t apply to me.” That would be a mistake.

If you use Claude Code, Cursor, or any agentic coding tool, you’re already making implicit policy decisions:

  • What files can the agent read? (Generally: everything in your repo, including .env files)
  • Can it execute terminal commands? (Generally: yes, with minimal confirmation)
  • Can it make external requests or call APIs? (Depends on your MCP server configuration)
  • Is there any record of what it did during the session? (Usually: only in your terminal history)

The new employee analogy works well here. When you onboard a human dev, you give them access to what they need for the job — not to the entire company filesystem. You set up SSO so you can revoke access from one place. You maintain audit logs to understand what happened if something goes wrong.

Your AI agents deserve — and frankly require — the same discipline.

The practical checklist

Here’s what applying this principle means in practice within a development workflow:

Scope your agent’s access. Don’t point it at your entire home directory or a whole monorepo by default. Work in delimited contexts where possible.

Audit your MCP server permissions. Every MCP server you add is a new surface of capabilities. Review what each one can actually do — don’t install them blindly.

Read what your agent is doing. Claude Code’s session logs and commit history are your audit trail. Use them. If an agent made a change you didn’t expect, you want to know before it reaches production.

Treat .env and credentials as forbidden zones. Explicitly configure your agents to exclude sensitive file patterns. Don’t rely on the assumption that “they won’t look there.”

Think about trust between multiple agents. If one agent can call another agent (or trigger workflows via webhooks), that chain of trust multiplies. Each hop is an additional potential attack surface.

The bigger picture: orchestration is the new frontier

Gabe Goodhart from IBM made a point that reframes the entire conversation: “It’s a buyer’s market for models. The model itself won’t be the main differentiator. What matters now is orchestration — combining models, tools, and workflows.”

In 2026, everyone has access to good models. The competitive advantage goes to teams that build systems around those models — and systems require governance, not just capability.

The devs who will get the most out of AI agents aren’t the ones who give them the most access. They’re the ones who give them exactly the right access, along with the visibility to know what’s actually happening.

That’s not a limitation on what agents can do. It’s what makes them trustworthy enough to do more.