Skip to main content
Amla Labs
← back to blog

Agents That Can Actually Do Things

Enterprise agents that demo autonomous refunds ship with 'click to approve' buttons. Here's why—and what changes when authorization is solved.

agents authorization enterprise security trust

Coding agents write files and run commands. Computer use agents click and type. But watch what happens when an enterprise agent needs to touch money, customer data, or production systems.

“I’ve prepared the refund for $47.50. Click here to approve.”

“I found the account discrepancy. Ready to submit the adjustment?”

“Here’s the configuration change. Confirm to apply.”

For low-stakes actions, agents act autonomously. For anything consequential, a human reviews, approves, clicks the button. The agent that demoed autonomous refunds ships with a confirmation dialog.

This isn’t a failure of AI capability. It’s a failure of authorization infrastructure.

Why Agents Can’t Act

The pattern is consistent across enterprises. An engineering team builds an agent that could save hours of manual work. It goes to security review. Security asks reasonable questions:

  • What happens if the agent is compromised?
  • What if it hallucinates a valid-looking but wrong action?
  • Can you guarantee it won’t exceed its authority?
  • How do we audit what it did and why?

The team can’t answer these questions with cryptographic guarantees. They can point to if-statements and prompt engineering. They can show guardrails that an attacker—or a sufficiently confused agent—could bypass.

Security says no. Or security says yes, but only with human-in-the-loop for every consequential action.

The agent ships as a copilot. It suggests. Humans execute.

What the team built:            What shipped:

┌─────────────────────┐         ┌─────────────────────┐
│   Autonomous Agent  │         │   Suggestion Agent  │
├─────────────────────┤         ├─────────────────────┤
│ • Reads data        │         │ • Reads data        │
│ • Reasons           │         │ • Reasons           │
│ • ACTS              │   →     │ • Proposes          │
│ • Reports results   │         │ • Waits for human   │
└─────────────────────┘         │ • Human acts        │
                                │ • Reports results   │
                                └─────────────────────┘

         40% cost reduction            15% cost reduction
         (projected)                   (actual)

The business case erodes. The agent that was supposed to handle 80% of tickets autonomously now handles 30%, with a human clicking “approve” on each one. The human becomes a bottleneck, not an overseer.

The Authorization Gap

The problem isn’t that security teams are paranoid. The problem is that they’re right.

SailPoint’s 2025 survey of enterprise security professionals found that 80% of organizations have already encountered unintended actions by their AI agents. Nearly a quarter (23%) report that AI agents have been tricked into revealing access credentials. Agents have gone rogue—accessing unauthorized systems (39%), downloading sensitive data (32%), sharing restricted information (33%).

And yet: 82% of organizations already use AI agents, while only 44% have policies to secure them. The gap between adoption and authorization is vast.

Traditional authorization wasn’t designed for autonomous actors. It assumes:

  • Identity is static. A user authenticates once, then acts within their permissions.
  • Actions are direct. The authenticated entity performs the action.
  • Speed is human. There’s time to review, intervene, audit.

Agents break all three assumptions:

  • Identity is delegated. The agent acts on behalf of a user, or on behalf of another agent, or on behalf of a workflow that no longer has a clear human principal.
  • Actions are indirect. Agent A calls Agent B calls Agent C. Which permissions apply?
  • Speed is machine. Thousands of actions per minute. No human can review in real-time.

There’s a deeper problem too. Even when an agent has legitimate credentials, it can exercise the wrong authority for a given transaction. This is the confused deputy problem—an agent with access to multiple capabilities might use Customer A’s refund authority to process Customer B’s transaction. The credentials are valid. The action is unauthorized. And there’s no structural mechanism to prevent it.

When security teams lack tools to express “this agent can issue refunds up to $500, only for customers who initiated a complaint, only during this transaction, and this guarantee is cryptographic not policy-based”—they fall back to the one control they trust: a human in the loop.

What Changes When Authorization Works

Imagine authorization infrastructure that lets you express:

Scoped authority. Not “this agent can access Stripe” but “this agent can issue refunds ≤ $500 to the customer who initiated this conversation.”

Cryptographic enforcement. Not an if-statement the agent could bypass, but a signed constraint verified at the gateway before any action executes.

Auditable chains. Not “the agent did something” but “here’s the exact delegation path: user → orchestrator → refund-agent → Stripe, with constraints tightening at each hop.”

Theft-resistant tokens. Not bearer credentials an attacker could reuse, but capability chains bound to a designated executor. Intercept the token? Useless without the executor’s signing key.

Transaction binding. Not “this agent has these capabilities” but “this capability is designated for this specific transaction.” The agent can’t accidentally (or maliciously) apply Customer A’s authority to Customer B’s transaction.

Now security review looks different:

“Can you guarantee it won’t exceed its authority?” — Yes. The capability chain encodes amount ≤ 500 as a cryptographic constraint. The gateway verifies the constraint before forwarding to Stripe. The agent never sees the Stripe API key. There’s no code path that bypasses verification.

“What if it’s compromised?” — Blast radius is bounded. The attacker gets a capability for this customer’s refund transaction, this transaction, up to $500. They cannot pivot to other customers, exceed the amount, or persist access beyond the transaction.

“How do we audit?” — Every action carries its full provenance chain. We can reconstruct: who initiated, what was delegated, which constraints applied, what executed.

The agent ships. Not as a copilot. As a colleague with clearly bounded authority.

From Copilots to Colleagues

The terminology matters. A copilot assists. It sits beside you, makes suggestions, waits for your input. The human remains the actor.

A colleague acts. Within their role, their scope, their authority. You don’t approve every email a colleague sends. You trust the boundaries of their position.

The shift from copilot to colleague requires trust infrastructure—mechanisms that make delegation safe, bounded, and verifiable.

COPILOT MODEL                      COLLEAGUE MODEL

Human ←→ Agent                     Human
    ↓                                 ↓
  [Agent suggests]                  [Delegates scoped authority]
    ↓                                 ↓
  [Human reviews]                   Agent
    ↓                                 ↓
  [Human acts]                      [Acts within bounds]
    ↓                                 ↓
  Result                            Result + Audit Trail

Bottleneck: Human review           Bottleneck: None (within scope)
Throughput: Human speed            Throughput: Machine speed
Trust: Implicit (human oversight)  Trust: Explicit (cryptographic)

Even the canonical literature on agentic design patterns acknowledges this problem. Agentic Design Patterns, a 424-page guide by Google’s Antonio Gulli, notes that “the primary drawbacks of Human-in-the-Loop are its inherent lack of scalability, creating a trade-off between accuracy and volume.” The industry knows HITL doesn’t scale. What’s missing is infrastructure that makes the alternative safe.

This isn’t about removing humans from decisions. It’s about removing humans from mechanical approval of actions that fall within pre-authorized bounds.

A $47.50 refund for a customer with a valid complaint doesn’t need human review. A $5,000 refund, or a refund for a customer flagged for fraud, might. The authorization system should express this—not as a prompt instruction the agent might ignore, but as a structural constraint the agent cannot exceed.

What Becomes Possible

When authorization infrastructure works, new architectures become viable:

Multi-agent workflows that ship to production. Today, most multi-agent systems stall at the prototype stage. Agent A can’t safely delegate to Agent B because there’s no way to scope what B can do. With capability chains, A delegates a subset of its authority to B. B cannot exceed what A granted. The chain is auditable end-to-end.

Graduated autonomy. Start an agent with narrow capabilities. As it demonstrates reliability, expand its scope—not by changing code, but by issuing broader capability chains. Revoke instantly if something goes wrong.

Cross-organizational agent collaboration. Your agent calls a vendor’s agent calls a partner’s agent. Each hop attenuates authority. No organization grants more than necessary. The chain proves exactly what was authorized at each boundary.

Agents that handle money. Payment agents, refund agents, procurement agents. Real financial authority, bounded cryptographically. Not “the agent has the company credit card” but “the agent can spend ≤ $1,000 on approved vendor categories for this purchase transaction.”

After-hours operations. The 3am alert doesn’t page a human for mechanical remediation. An agent with scoped infrastructure access handles it. The blast radius is bounded. The audit trail is complete. Humans review in the morning.

The Trust Threshold

Every organization has an implicit trust threshold—a level of risk below which human review isn’t worth the cost.

For most companies, that threshold is higher than they’d like. Not because they’re paranoid, but because they lack tools to verify that an action falls below the threshold.

When authorization is opaque, the only safe answer is human review. When authorization is cryptographic, auditable, and structurally bounded, the threshold can rise.

An agent that can prove “this action is within my designated scope, here’s the chain that authorizes it, and I cannot exceed these bounds” is an agent that can be trusted with real work.

Not infinite trust. Not unsupervised trust. Appropriate trust, backed by infrastructure that makes verification cheap and guarantees meaningful.

What We’re Building

Amla Labs builds the trust infrastructure that lets agents act.

We don’t replace your identity provider or your secrets manager. We add the missing layer: capability chains that bind authority to specific transactions, attenuate at every delegation, and verify before execution.

The refund agent gets a capability chain, not an API key. The chain says: this customer, this transaction, up to $500. The gateway enforces it. Security signs off. The agent ships.

That’s what we mean by agents that can actually do things.