Securing AI Agents as Identities: A Small-Team Guide

By Lazar Milicevic · Published October 12, 2026 · 12 min read

You wired an AI agent into your inbox, CRM, and billing tool last quarter. It authenticates with an API key a teammate pasted into an environment variable, nobody remembers which scopes it has, and there is no entry for it anywhere in your user list. This guide walks through treating that agent like what it is, a member of your workforce, and securing it with a process small teams can run in an afternoon.

Why agents are an identity problem, not just an AI problem

An AI agent that logs into systems, reads data, and takes actions is an identity, and it needs the same lifecycle controls a human employee gets: a named owner, a defined role, scoped access, and a revocation path. Most small stacks give agents none of these.

Think about how you onboard a person. They get a role, a set of entitlements, and a manager who is accountable for their access. When they leave, credentials are revoked. Now think about how the average automation gets onboarded: someone generates a token with whatever scopes made the error go away, pastes it into a config file, and moves on. There is no manager, no review date, and no offboarding.

The scale of the gap depends on who you ask, and the numbers measure different populations, so don't average them or treat any one as the ratio:

• JumpCloud's Q3 2026 research (vendor-run, n=800 IT leaders in the US and UK) reports that non-human identities outnumber human users in 83% of organizations, and that only 21% have governance controls built specifically for them. VentureBeat, presented by JumpCloud
• Palo Alto Networks' 2026 Identity Security Landscape reports machine identities, including AI agents, outnumbering human identities 109:1. Palo Alto Networks
• The Cloud Security Alliance, citing Entro Security, puts the average at near 45:1 across enterprises and as high as 144:1 in cloud-native environments, up from 92:1 in the first half of 2024. Cloud Security Alliance
• KPMG's Cybersecurity Considerations 2026 report is cited as finding 80:1 in the average enterprise. NHIMG summary

One caveat before you panic or relax: most of these figures come from enterprise surveys. Don't extrapolate them to a ten-person company. Your ratio is almost certainly smaller in absolute terms, but the shape of the problem is the same, and a small team has fewer people watching for it. If you have more automations than employees, which is common even at five people, you are already running a non-human workforce.

The four-stage framework: discover, register, restrict, govern

The cleanest way to organize this work is the four-stage model JumpCloud lays out in its Agentic IAM material: discover every agent, register each as a formal identity with a named human owner, manage access with least privilege and zero standing credentials, and govern behavior continuously. JumpCloud

You don't need JumpCloud, or any specific vendor, to use this model. It's a sequence, and the order matters, because you can't register what you haven't found and you can't restrict what you haven't registered.

The rest of this post goes stage by stage.

Stage 1: Discover every agent you actually have

You can't secure an agent you don't know exists, so start with an inventory built from the systems that issue credentials, not from memory. Memory misses the Zapier zap someone built in 2024, the Custom GPT with Actions, and the "temporary" script on a laptop.

Where to look, in rough order of yield:

1. API key and token pages in every SaaS you use (CRM, email platform, accounting, payment processor, project tool, source host). Each key is a non-human identity, whether or not it's called an agent.
2. OAuth app authorizations in your identity provider and in each SaaS: "Connected apps," "Authorized integrations," "Third-party access."
3. Automation platforms (Zapier, Make, n8n, and similar): every connection they hold is a credential someone granted.
4. Cloud consoles: service accounts, IAM roles, access keys.
5. Repos and config files: .env files, CI/CD secrets, MCP config files.
6. Browser extensions and desktop AI tools that were granted access to mail, calendar, or drive.

If you want a fast starting point for the repo sweep, a secret scanner will show you where credentials already leaked into code:

# Scan the current repo history for committed secrets (gitleaks)
gitleaks detect --source . --log-opts="--all" --report-path gitleaks-report.json

# Quick grep for common env-file patterns across your projects
grep -rIn --include=".env*" --include="*.yml" --include="*.json" \
  -E "(API_KEY|SECRET|TOKEN|PASSWORD)\s*[=:]" ~/projects 2>/dev/null | head -50

Treat anything these turn up as already exposed. Rotate it first, then register it properly.

The output of discovery is a raw list. Don't try to make it pretty yet. You'll probably find duplicates, dead integrations from tools you abandoned, and at least one key nobody can explain. That last category is your first cleanup target, because an unexplained credential with live access is exactly what attackers hope you have.

Stage 2: Register each agent as a formal identity with a human owner

Registration means every agent gets a record with a name, a purpose, a named human owner, a scope list, and a review date. The owner is the part that matters most: when something goes wrong at 2 a.m., "the automation" can't be paged, but a person can.

You don't need an identity governance platform for this on day one. A version-controlled YAML file works, and it has a nice side effect: changes to agent access show up in pull requests.

# agents.yaml - registry of non-human identities
agents:
  - id: inbox-triage-agent
    purpose: Classify inbound email and draft replies for human approval
    owner: jane@yourcompany.com        # accountable human, not a team alias
    created: 2026-09-14
    review_by: 2026-12-14              # re-justify access every quarter
    systems:
      - name: gmail
        scopes: ["gmail.readonly", "gmail.compose"]   # no send, no delete
      - name: crm
        scopes: ["contacts:read"]
    credential_type: oauth_refresh_token   # short-lived access tokens issued from this
    can_act_without_approval: false
    offboarding: revoke OAuth grant, delete refresh token, archive logs

  - id: invoice-reconciler
    purpose: Match payments to open invoices, flag mismatches
    owner: sam@yourcompany.com
    created: 2026-10-01
    review_by: 2027-01-01
    systems:
      - name: accounting
        scopes: ["invoices:read", "payments:read"]
    credential_type: api_key_restricted
    can_act_without_approval: false
    offboarding: delete key in accounting settings, remove from secrets manager

Three rules keep this registry honest:

• One credential per agent. Sharing a key across three automations means you can't tell them apart in logs and can't revoke one without breaking the others. The OWASP Non-Human Identities Top 10 lists NHI reuse as its own risk category for exactly this reason. OWASP NHI Top 10
• The owner is a person. If that person leaves, the registry forces a handoff, the same way an offboarding checklist forces one for their laptop.
• Write the offboarding step at creation time. OWASP ranks Improper Offboarding first in its 2025 NHI Top 10. Decommissioning is the step everyone skips, and it's the easiest to define up front, when you remember exactly what you connected.

Stage 3: Restrict access with least privilege and zero standing credentials

Least privilege means each agent gets only the scopes its job requires, and "zero standing credentials" means it holds no long-lived secret that works forever. Together they shrink the damage of any single compromise to something you can survive.

OWASP defines Overprivileged NHI (NHI5:2025) as non-human identities assigned far more privileges than their function requires, and notes that a compromised over-privileged NHI lets attackers exploit all those excess permissions. OWASP For a sense of how common this is: Entro Security's 2025 State of Non-Human Identities report, as cited by CSO Online, found that 97% of NHIs have excessive privileges. CSO Online That is one vendor's dataset, but it matches what most inventories turn up: the scope list nobody trimmed after the integration started working.

A practical way to scope an agent is to run it, record what it actually calls, and cut everything else:

# Audit an agent's real API usage over a week, then compare to granted scopes.
# Pseudocode-level example: adapt the log source to your stack.
from collections import Counter

granted = {"gmail.readonly", "gmail.compose", "gmail.send", "gmail.modify"}

def scopes_used(log_lines):
    used = Counter()
    for line in log_lines:
        # your gateway or proxy log should record the API method per call
        if "messages.list" in line or "messages.get" in line:
            used["gmail.readonly"] += 1
        elif "drafts.create" in line:
            used["gmail.compose"] += 1
        elif "messages.send" in line:
            used["gmail.send"] += 1
    return used

used = scopes_used(open("agent-gateway.log"))
unused = granted - set(used)
print(f"Revoke candidates: {sorted(unused)}")
# -> Revoke candidates: ['gmail.modify', 'gmail.send']

Then replace standing secrets with short-lived ones where the platform allows it:

A detail worth knowing if you build with MCP, the protocol many agents now use to reach tools. The MCP specification (version 2025-11-25) requires servers to validate that an access token was issued specifically for them (an audience check) and to reject tokens meant for someone else. It also requires clients to implement PKCE with the S256 challenge method when technically capable. MCP specification Two cautions: authorization in MCP is optional, and stdio-based servers typically pull credentials from the environment rather than an OAuth flow. Aembit So "it uses MCP" does not mean "it's authenticated properly." Check what your specific servers do. Also note that newer MCP revisions exist; the official 2025-11-25 text is what I'd cite for hard requirements, and you should check the current specification before building against it. OAuth 2.1, which the MCP authorization model builds on, is still an IETF Internet-Draft rather than a finalized RFC.

On the vendor side, JumpCloud announced on September 10, 2026 that its PAM MCP Server, which replaces shared API keys with isolated agent identities, is scheduled before the end of Q4 2026. That's a roadmap item, not a shipped feature as of the announcement, so don't plan around it yet. JumpCloud press release The underlying idea, isolated per-agent identities in place of shared keys, is something you can approximate today with the registry and credential rules above.

Stage 4: Govern behavior continuously, not once

Governance is where you find out whether the controls from Stages 1-3 are working: logging what each agent did, reviewing access on a schedule, and having a kill switch you've tested. A registry you wrote once and never opened again is a stale spreadsheet.

Minimum viable governance for a small team:

Logging with identity attached. Every action should be traceable to a specific agent identity, not just "the API key." If three agents share a key, your logs can't answer "which one deleted that record?" A structured log entry per action is enough:

{
  "ts": "2026-10-12T14:03:22Z",
  "agent_id": "inbox-triage-agent",
  "owner": "jane@yourcompany.com",
  "action": "drafts.create",
  "target": "gmail:thread/18f3c...",
  "approved_by": null,
  "outcome": "success"
}

A quarterly access review. Put it on the calendar, tied to the review_by field in the registry. For each agent, the owner answers three questions: Is it still used? Are its scopes still the minimum? Is the offboarding step still accurate? Anything that fails gets revoked. This is the same review you'd run for human accounts, just applied to the other half of your workforce.

Anomaly checks you can actually run. You don't need a SIEM. Start with cheap rules: an agent touching a system not in its registry entry, activity outside its normal hours, a sudden jump in call volume, a credential used from a new IP. Even a weekly script that diffs "systems accessed" against "systems registered" catches a lot.

A tested kill switch. For each agent, know the exact steps to cut it off, and run them once in a non-emergency. The first time you try revoking an OAuth grant should not be during an incident.

Human-in-the-loop for irreversible actions. Sending money, deleting data, emailing customers, and changing permissions should require approval unless you have a very good reason. The can_act_without_approval: false field in the registry makes that a decision someone had to make on purpose.

Where standards stand, and what to do while they settle

There is no finished standard to certify against yet, so build on principles that will survive whatever lands. NIST's NCCoE released a concept paper, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," proposing a project to demonstrate how identity standards and best practices apply to software agents. NIST NCCoE It was published on February 5, 2026, with a public comment deadline of April 2, 2026. CSA research note It is a draft concept paper that sets no controls, and as one analysis notes, NIST has not published a standard for AI agent authorization, so there is nothing to certify against. ARMO

Meanwhile, Gartner's Top Cybersecurity Trends for 2026 lists "IAM adapts to AI agents" as Trend 4, pointing to identity registration and governance, credential automation, and policy-driven authorization for machine actors. Gartner That lines up closely with the four stages above, which is the useful takeaway: the direction of travel is consistent even while the formal standards are not. If you've registered agents, scoped them tightly, and logged their actions, you're aligned with where the guidance is heading.

A one-afternoon checklist

If you do nothing else, do this in order:

1. List every API key, OAuth grant, and automation connection across your SaaS tools (about an hour).
2. Run a secret scan on your repos and rotate anything found.
3. Create agents.yaml with an owner, purpose, scopes, and review date for each agent.
4. Split shared credentials so each agent has its own.
5. Trim scopes to what logs show the agent actually uses.
6. Require human approval for anything irreversible.
7. Add the quarterly review to your calendar, with the first date set.

None of this requires buying anything. It requires deciding that agents are staff, and treating their access with the same seriousness you'd give a new hire's.

Putting this into practice

The approach we recommend is to provision each agent as its own identity from the start: scoped credentials rather than a shared admin key, clear MCP boundaries that define which tools and data an agent can reach, and an audit trail that ties every action back to a specific agent and a named human owner. The registry-and-review process described above is one way to do that, and you can adapt it to whatever stack your business already runs.

Set this up early, because cleaning up a pile of untracked automations later is far more painful than doing it at the start. If you already have that pile, the discovery sweep in Stage 1 is the place to begin.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.