AI Agents: Execution Rights Without Custody#

Most agents can recommend. Hightop lets them operate.

An AI Agent in Hightop is a named control profile for an external agent or workflow. You give it a job, a set of allowed actions, approved payment paths, spending limits, and time limits. Your external agent can then act through the Hightop API inside that lane without owning the account itself.

This is the core idea behind Hightop's control model: agents get execution rights, not custody.

When you set boundaries for an agent, those boundaries are not just suggestions in the app. If an agent or API request tries to exceed them, the control layer blocks the action before funds move.

The app is where you configure the lane. Key boundaries are enforced onchain by open-source smart contracts, so you can verify the rules independently — they are not locked inside Hightop's servers.

Why Hightop Uses Agents Instead of Shared Wallet Access#

Agent workflows break down when money enters the picture.

An agent might need to:

• pay for data, inference, or compute
• keep vendor subscriptions online
• sweep idle cash into Earn
• route incoming revenue
• borrow working capital before revenue settles
• collect usage-based revenue for work it performs

The problem is not capability. The problem is trust.

If you give an agent private keys or unrestricted wallet access, one bug, exploit, hallucination, or bad decision can drain the wallet or cause a complete loss of funds. If every money action still needs your manual review or approval first, the agent is no longer truly autonomous. It cannot operate 24/7, respond in real time, or keep money moving without you in the loop.

Hightop solves this by letting agents operate inside a lane you control. Key boundaries are enforced by the onchain control layer — not just app or backend logic.

What You Configure Per Agent#

Your external agent might live in an agent framework like OpenClaw or Hermes, or in your own stack. It uses an API key to send requests to Hightop.

The Hightop agent configuration is the control profile attached to that caller. It defines what that external agent is allowed to do with money once the request reaches Hightop.

Each agent can have its own:

• permissions
• spending and activity limits
• payment paths
• allowed assets and venues (the markets and services your agent can interact with)
• expiry window

That is why one Hightop account can safely support multiple agents with different jobs instead of treating them like one shared super-user.

Depending on the permissions you enable, an agent can:

• send recurring payments to approved vendors (called Payees in Underscore Protocol)
• create one-off payments for ad hoc payouts
• transfer to pre-approved destinations you trust
• move balances into or out of Earn
• buy, sell, and rebalance supported assets
• manage supported borrowing actions

Each capability can be turned on or off independently. One agent can be narrow and operational. Another can be broader and more strategic.

When you configure an agent, you are also scoping each capability with boundaries such as:

• per-transaction, per-period, and lifetime limits
• maximum number of actions in a period
• cooldowns between actions
• allowed assets
• approved venues or protocol integrations
• approved vendors and payment paths
• activation delay and expiry

That is what turns "this agent can pay" into something much more precise, such as:

• "this agent can pay approved inference and compute vendors"
• "only in USDC"
• "up to $1,000 per month"
• "with no more than 20 payments per week"
• "and only until this contract expires"

How Hightop Validates Agent Actions#

Hightop does not just check permissions once and hope the rest works out.

Every action has to fit the stack of rules that applies to it: account-wide, agent-specific, and path-specific, with the tightest rule winning. Agent Permissions and Limits covers that stacking model in detail. The piece worth knowing here is how the smart contract actually runs those checks for each agent request — in two stages, before and after the action.

Before an action executes, the system checks questions like:

• is this agent active yet
• has it already expired
• does it have permission for this action family
• is it touching an allowed asset
• is it using an allowed venue
• is the payment path and recipient allowed
• has it hit a cooldown or action-count limit

After the action is assembled, the system checks the financial outcome against the configured boundaries, including things like:

• per-transaction value
• period spend
• lifetime spend

Those checks and the action itself execute atomically. If the action would break the rules, the transaction fails instead of partially going through. Even a buggy integration or compromised API key cannot push an action past that control layer.

A compromised API key can still use whatever permissions and limits you intentionally granted to that agent. That is why scoping each agent's lane tightly still matters.

What an Agent Cannot Do#

An agent cannot simply do whatever it wants.

Unless you explicitly allow it, an agent cannot:

• exceed its spending or activity limits
• touch assets outside its allowed set
• use unsupported or disallowed venues
• pay destinations that are not approved for the chosen payment path
• bypass cooldowns, delays, or expiry windows
• silently widen its own permissions
• change its own limits
• add other agents or escalate its own authority

Regardless of permissions, an agent can never:

• add new trusted destinations
• activate or confirm proposed vendors
• change account-wide rules

An agent with the right permission can propose a new recurring vendor, but the account owner must confirm it before it becomes active.

These boundaries are enforced by the control layer, not just displayed in a dashboard.

The Right Shape of an Agent#

Think of a Hightop agent as a scoped control profile for an external agent or workflow — not as the full agent itself and not as a co-controller of the account.

In practice, the best agents are narrow.

• an inference agent that pays model APIs and compute providers does not need borrowing access
• a research agent that pays for paywalled APIs and datasets does not need broad payment authority across every vendor
• a procurement agent that buys output from specialized agents does not need broad treasury or trading powers

The tighter the mandate, the easier it is to trust the automation.

Who Controls What#

You do not manage wallets directly — Hightop handles that. But under the hood, your account is anchored by a control wallet: the wallet address that controls your account. Understanding it helps explain why the control model is trustworthy.

When you sign up for Hightop, we create that control wallet as an embedded wallet through Turnkey. That is the default control key for your account. If you want, you can later move control of the account to another wallet you control, such as a hardware wallet or a Safe (a multi-signature wallet that requires multiple approvals to act).

A compromise of Hightop's servers alone does not let an attacker steal funds. The control wallet is the wallet with authority to change your account's rules. With the default Turnkey embedded setup, an attacker would also need to compromise the user's email-based access path to take over that control wallet. If you later move control of the account to a hardware wallet, Safe, or another external wallet, the attacker would instead need to compromise that wallet's own keys or signing authority.

That means you control things like:

• when an agent is created
• what permissions it receives
• how broad or narrow its limits are
• when it is revoked or allowed to expire

The agent can operate inside the lane you give it. It does not get to redraw the lane.

That is the core mental model: execution rights, not custody.

Hightop agents are not account controllers. They do not hold the control wallet. They do not get open-ended power. The control wallet can add, update, remove, or extend agents. The agent can execute its job inside the lane, but it cannot grant itself new permissions, create peer agents, or widen the wallet's trust surface.

This is why Hightop models agents as scoped financial operators, not just credentials.

Agent Lifecycle#

An agent moves through a simple lifecycle:

1. Created: You add the agent in Hightop and define its role.
2. Waiting: If the agent has an activation delay, it cannot act yet.
3. Active: The agent can operate through the API within its rules.
4. Expired or Removed: The agent can no longer act.

This gives you operational flexibility without permanent, unlimited delegation. An agent cannot act before its activation delay ends or after its expiry window closes.

Example Agent Profiles#

Research Agent#

Pays for paywalled APIs, proprietary datasets, model inference, and compute within a fixed budget.

Operations Agent#

Keeps approved APIs, SaaS tools, inference vendors, and recurring service providers online.

Support Agent#

Helps power usage-based service flows, receive revenue, and keep approved service infrastructure online.

Cash Management Agent#

Moves idle balances into Earn, pulls funds back when needed, and supports tightly scoped cash-management or borrowing workflows.

Procurement Agent#

Buys one-time datasets, temporary compute, or specialized agent services through controlled one-off payments.

How AI Agents Work With Other Controls#

The agent concept is only one piece of the control layer.

• Agent Permissions and Limits defines what an agent can do and how far it can go.
• Recurring Payments defines which approved vendors an agent can pay repeatedly.
• One-Off Payments handles ad hoc payouts with optional review windows.
• Trusted Transfers covers instant transfers to your own highest-trust destinations.

Together, these give Hightop agents real execution power without blind trust.

When to Read This Page vs the Others#

Read this page if you want to understand:

• what an agent is in Hightop
• why agents are safe to use
• how execution rights differ from custody

Then go deeper:

• read Agent Permissions and Limits for the full rules model and the detailed parameter list
• read If an Agent Goes Off-Script if you want to understand blocked actions

If you want the lower-level protocol details and open-source code behind the control layer, see Technical References for the full map of protocol repos, technical docs, and live params tools. The Hightop team also built these protocols.