Before You Deploy AI: The Identity Questions Most Businesses Skip

Every business is being told to "adopt AI" right now. Most of the advice focuses on picking the right model, writing better prompts, or choosing which vendor's chatbot to plug into your workflow. Almost none of it covers the question that actually breaks deployments: who, or what, is the AI allowed to act as?

We've been doing identity and access work for twenty-plus years. The shift from human users to autonomous agents is the biggest change in IAM we've seen in that span, and the businesses moving fastest into AI are also the ones most likely to skip the part where they figure out the access model. Here are the questions worth answering before your AI ever touches production data.

1. Is your AI agent a user, a service, or something new?

When an AI agent reads a customer record, files a ticket, or sends an email on someone's behalf — whose identity is doing that? You've got three rough options, and most teams pick the wrong one by accident.

• Acting as the human user. The agent inherits the employee's permissions. Convenient, but the audit trail says the human did everything. If the agent goes sideways, the blast radius is one full employee's access.

• Acting as a service account. The agent has its own credentials, typically over-permissioned because nobody wants to keep narrowing the scope. Good audit isolation, terrible least-privilege.

• Acting as a first-class non-human identity. The agent has its own identity in your IdP (Okta, Entra), with policy-bound, time-scoped access distinct from any human or static service account.

The third option is what mature deployments look like. AWS Bedrock AgentCore, for example, supports native OIDC for agent identities. If your AI stack doesn't have an answer here, you're picking option one or two by default.

2. What does the agent need access to — and for how long?

The instinct is to give the agent read access to everything it might need, plus write access wherever its output goes. This is how you end up with an AI assistant that, six months later, has standing access to your CRM, your ticketing system, your file storage, and your email — none of which it actively needs most of the time.

Just-in-time elevation isn't a new idea, but it's especially important for non-human identities because there's no human to notice "why does this account have admin?" Build access patterns where the agent requests scoped credentials at task time, uses them, and surrenders them. Vault, Teleport, and newer AI-governance tools make this tractable.

3. What does your audit log actually capture?

If a regulator, customer, or your own incident response team asks "what did the AI do on Tuesday at 3 PM?" — can you answer? Most native AI platform logs capture model inputs and outputs. Far fewer capture the downstream API calls the agent made, with what credentials, against what systems.

The audit story has to span three layers: the prompt and response (model layer), the tool calls the agent made (orchestration layer), and the API and database access those tools triggered (system layer). Skip any one and you have an audit log that can't reconstruct what happened.

4. How are secrets handled inside the agent's runtime?

AI coding assistants like Claude Code, Cursor, and Windsurf will happily read your .env file, your AWS credentials, and your SSH keys if you let them. The same is true of agentic workflows that touch your codebase. We've seen real businesses with production database passwords sitting in the same repo the AI agent has full read access to.

The fix isn't hard, but it requires intent: ignore-files like .claudeignore, isolate secrets behind a broker (Vault, AWS Secrets Manager), use BuildKit secret mounts in containers, and never let an AI agent see a credential you wouldn't put in a public Slack channel.

5. What's your kill switch?

Every production AI deployment needs an answer to "what happens if this agent starts doing the wrong thing?" That means a way to immediately revoke its credentials, a way to roll back any actions it's taken, and a human-in-the-loop checkpoint for high-stakes actions like sending external communications, modifying customer records, or making payments.

The kill switch isn't paranoia — it's the same hygiene you apply to any production system. AI agents just make it more important because they act faster, at higher volume, and currently without good judgment about when to stop.

Where to start

If your business is six months into AI experiments and starting to think about putting agents into production workflows, the audit-and-design conversation should happen before the rollout, not after. HighArrow helps businesses work through these questions and build the identity and access foundation their AI deployments need.