Skip to main content
INS // Insights

Securing AI Agents: Scoped Tools and Short Creds

Updated September 2026 · 5 min read

Securing AI agents is an IAM problem that happens to involve a model. A production agent that can call tools — refund a customer, open a pull request, query a warehouse, rotate a secret — is a non-human identity with a language interface. Treating that as "AI automation" is how teams ship a bot with the same credentials as a senior engineer and a Slack channel for after-the-fact regret.

We build the permission plane: a tool gateway, short-lived credentials, and human-in-the-loop (HITL) on side effects that leave the sandbox. We do not sell an agentic SOC product and we do not write another "automate anything" essay. If you want IDE-assistant IAM, that is a sibling: AI coding assistant IAM permissions. This article is the agent that runs in your environment, not the one in the editor.

NIST's AI Risk Management Framework treats govern / map / measure / manage as the loop. For a mid-market production agent, the concrete loop is: which tools exist, which identity may call them, how long the credential lives, who approves irreversible actions, and how you tell agent from human in the log.

Securing AI Agents Is Not Chatbot Policy

A chatbot that answers from a corpus needs retrieval controls and DLP. An agent that acts needs those plus:

  • Tool allowlists per agent role — not one MCP dump of every internal API
  • Argument constraints — refund tool cannot take amount > X without a ticket id
  • Caller identity — the agent has its own principal, never the operator's standing cloud keys
  • Session credentials — minted per task, dead at the end
  • HITL — production writes, payments, identity changes, and data exports pause for a person

If any of those is "the model will be careful," you do not have a control. You have a hope.

Scoped Tools: A Gateway, Not a Pile of Tokens

We put tools behind a gateway the agent must call. The model never sees raw AWS keys, Salesforce passwords, or the warehouse admin DSN. It sees tool names and JSON schemas. The gateway enforces scope.

TOOLS = {
    "warehouse_query": {
        "role": "agent-analytics-readonly",
        "tables": ["analytics.*"],
        "deny": ["customers.ssn", "payments.pan"],
        "credential": "session",  # minted for this task
        "hitl": False,
    },
    "issue_refund": {
        "role": "agent-billing-refund",
        "max_amount": 75,
        "credential": "session",
        "hitl": True,  # human must approve the exact payload
    },
    "prod_deploy": {
        "role": None,
        "hitl": True,
        "allowed": False,  # not in this agent's catalog
    },
}

def invoke(agent_id, tool, args, task_id):
    spec = TOOLS[tool]
    assert tool in catalog(agent_id)
    creds = mint_session(spec["role"], task_id, ttl=900)
    if spec["hitl"]:
        return queue_approval(agent_id, tool, args, creds)
    return run_tool(tool, args, creds)

Three rules we will not relax:

  1. An agent that should not deploy cannot see a deploy tool. Omitting it from the schema is the control. Prompt text that says "please don't" is not.
  2. High-impact tools have numeric and object limits in the gateway, not in the system prompt.
  3. The gateway logs tool, args hash, task id, agent id, approver. The model vendor's chat log is not the audit trail.

This is closer to API authorization than to "AI safety." We treat it that way.

Short-Lived Creds: The Agent Is a Workload

Standing API keys in the agent runtime are the same defect as standing keys in CI. We mint from the same families we already ship:

  • AWS: task or session role, or federation — see workload identity federation
  • Azure: managed identity when the runtime is on Azure
  • SaaS: OAuth tokens with tight scopes, refreshed per task, revoked at end

The agent process holds the gateway identity. The gateway holds the ability to mint the tool identity. Compromise of the model session should not yield the warehouse admin. Compromise of the gateway is serious — we keep that service small, locked down, and on a separate role from the LLM host.

Duration stays in minutes. A four-hour refund token is a standing key with extra steps.

Human-in-the-Loop Where the Blast Radius Is Real

HITL is not "a human glances at Slack." It is an approval object:

  • Exact tool + arguments (amount, target id, environment)
  • Agent id and task id
  • Expiry (stale approvals die)
  • Approver identity, logged

We use HITL for money movement, identity changes, production schema/data writes, and anything that pages a customer. We do not use HITL for every read in a research sandbox — that trains people to approve blindly.

For coding agents that want to apply infrastructure, the pattern matches the assistant article: plan in staging, apply in prod only after a person. Production agents that are the product (support, billing ops) get the refund-shaped gate above.

Logging So Incidents and Audits Can Separate Actors

Every tool call carries actor_type=agent, agent_id, task_id, parent_user (who started or approved the task). SOC 2 access samples will eventually ask who did this. "The chatbot" is not an identity. CloudTrail, app logs, and the gateway must agree.

We also record denials: tool not in catalog, argument rejected, HITL expired. Denials are how you know the gateway is doing work. A log with only successes is a sampling problem.

What This Engagement Is Not

  • Not a generic RPA / "AI automation for ops" build
  • Not an alert-triage SOC product
  • Not a promise that the model cannot be jailbroken — the gateway assumes it can
  • Not FedRAMP or SOC 2 certification of the agent

We implement the IAM and the gateway on the same production SaaS habits we already use: least privilege, short credentials, evidence you can export. Security automation is the capability home. Full-stack development shows up because the gateway is an application, not a policy PDF.

Discuss securing your AI agent build: rutagon.com/contact · 907-841-8407 · contact@rutagon.com.

Frequently Asked Questions

Is securing AI agents the same as securing an LLM chat feature?

No. Chat features need retrieval and output controls. Agents that invoke tools need a gateway, per-tool identities, and HITL on side effects. You may need both. They are not the same design.

Should the agent use the operator's cloud credentials?

No. That conflates human and agent in every log and inherits whatever standing access the operator has. The agent gets its own principal; the operator approves when HITL says so.

Can we skip HITL if the model is "aligned"?

We do not treat model behavior as a control for refunds, identity changes, or production writes. HITL is the control. Alignment is a quality goal.

How does this differ from IAM for AI coding assistants?

Coding assistants live in an IDE and should be scoped to staging plus a human apply step. Production agents are long-running services with a tool catalog. Same least-privilege idea, different runtime and different gateway.

What do you need to start a diagnostic?

The agent's tool list, where it runs, which systems those tools touch, and whether any standing keys are already in the runtime. We will not start from a slide that says "autonomous ops" with no catalog.