Agent Permissions and Limits#

Permissions define what an agent is allowed to do.

Limits define how far it is allowed to go.

Together, they form the core control layer for Hightop agents. Key boundaries are enforced onchain by open-source smart contracts — the rules are public and verifiable, not locked inside Hightop's servers. If you want the lower-level protocol details, see the Underscore Protocol and the GitHub repo. The Hightop team also built this protocol.

In Hightop, the agent is the control profile attached to your external agent or workflow, not the full agent system you built outside Hightop.

This is where you translate trust into rules: which actions are allowed, which assets or venues can be touched, how much can move, how often an agent can act, and when access should end.

AI Agents explains the model. This page explains the actual parameters.

When you configure an agent, you are answering a short set of practical questions like:

• Which action categories can this agent use?
• How much can it do per action?
• How much can it do per day, week, or month?
• How many actions can it take in that period?
• Which assets can it touch?
• Which venues can it use?
• Which payment paths can it use?
• How much slippage can it tolerate on buy, sell, or rebalance actions?
• Should Hightop block the action if price data is missing?
• When does access start?
• When does its access end?

You do not need to configure every one of these for every agent. Some controls only matter if that agent can use a specific action path, and some can inherit broader defaults. The safest approach is to start narrow and only tune the rules that matter for that agent's job.

Where Each Control Lives#

This page covers the agent-wide rules layer.

The payment-primitive pages cover the controls that only make sense inside those specific paths.

The simplest rule is:

• if the control applies to the agent across many kinds of actions, it belongs here
• if the control only exists inside one payment path, it belongs in that path's page

Permissions vs Limits#

The easiest way to understand the model is:

• Permissions answer: "Can this agent perform this category of action at all?"
• Limits answer: "If yes, how much, how often, and under what conditions?"

An agent usually needs both.

For example:

• an agent may have permission to send payments
• but only up to a per-transaction limit
• only within a monthly budget
• only using approved assets
• only to approved destinations

There is one more important distinction:

• agent-wide rules apply across many kinds of actions
• path-specific rules only apply inside one payment path

That is why an agent can have payment permission in general, but still be blocked by the rules of a specific recurring relationship, one-off payment, or trusted destination.

Permission Categories#

The current model groups permissions into these categories:

Payment Permissions#

• send approved recurring payments
• create one-off payments
• use trusted destinations if explicitly allowed
• propose new recurring vendors for approval if that workflow is enabled

Treasury and Asset Permissions#

• buy and sell supported assets
• rebalance portfolio targets
• move balances into or out of Earn

Borrowing Permissions#

• manage supported borrowing actions such as adding collateral, borrowing, or repaying

In Hightop, this is a narrower capability family. The detailed constraints still come from the same limits, asset rules, venue rules, and timing rules described elsewhere on this page.

Administrative Permissions#

• perform specific high-trust account-management actions if Hightop exposes them to the agent

This category is intentionally narrow and high-trust. Most agents will not need it.

The important idea is that permissions are granular. You do not have to create an all-powerful agent.

Example Configurations at a Glance#

Before diving into the detailed parameters, here are concrete examples of how permissions and limits combine in practice:

Research Agent#

• Can send recurring payments and one-off payments
• USDC only
• $500 per payment
• $5,000 monthly limit
• one-hour cooldown

Good for data feeds, model inference, and compute.

Operations Agent#

• Can send recurring payments only
• approved data, inference, and compute providers only
• stablecoins only
• $250 per payment
• $2,000 weekly limit
• 24-hour cooldown
• 90-day expiry

Good for keeping core agent infrastructure online without broad account powers.

Procurement Agent#

• Can create one-off payments only
• USDC only
• $200 per one-off purchase
• $1,000 weekly limit
• 30-day expiry

Good for one-time datasets, temporary compute, or specialized agent services without broad recurring-payment authority.

Cash Management Agent#

• Can move balances into or out of Earn
• Can manage supported borrowing actions
• approved assets and venues only
• $25,000 per action
• $100,000 monthly limit
• 2 actions per day
• 30-day expiry

Good for tightly scoped cash management without giving the agent broad payment authority.

The rest of this page explains every parameter behind configurations like these.

How Payment Permissions Actually Work#

Giving an agent payment permission does not mean "this agent can pay anyone in any way."

The real model has three layers:

1. the agent must be allowed to use that payment path at all
2. the action must fit the account-wide and agent-specific limits for that agent
3. the specific recurring relationship, one-off payment, or trusted destination must already be valid for that path

A payment can still fail because it exceeds a per-transaction cap, a per-period budget, a lifetime budget, an action-count limit, a cooldown, or an allowed-asset rule — even if the agent has the right permission.

In other words:

• permission opens the lane
• agent-wide limits define how far the agent can go inside that lane
• path-specific rules decide whether this exact payment is allowed

The detailed agent-wide caps and timing rules are covered later in Financial Limits and How Rules Stack.

Recurring Payments#

Recurring payments split into two ideas:

• can the agent pay an already active recurring vendor
• can the agent propose a new recurring vendor for approval

Those are not the same permission, and neither one overrides the relationship's own rules.

One-Off Payments#

One-off payments split into creation and execution.

• an agent may have permission to create a new one-off payment
• an agent may also need permission to execute an existing one-off payment

One-off payments can also use an instant threshold: smaller amounts can clear immediately, while larger ones wait behind the configured review delay. That threshold is part of the one-off payment path, not a general agent-wide payment permission.

Trusted Transfers#

Trusted transfers are separate again.

An agent may have permission to use a trusted destination for payment, but that does not mean it can manage the trusted list itself.

Adding a new trusted destination is reserved for your control wallet. Using a trusted destination is separate from confirming, cancelling, or removing existing trusted-list entries.

For the exact per-path checklist each payment type evaluates, see Payment Paths and Recipient Rules.

Financial Limits#

Per-Transaction Limits#

Cap the size of any single action.

Example:

• no payment above $500
• no one-off service purchase above $2,500

This prevents one large mistake from turning into one large loss.

Period Limits#

Cap how much an agent can do inside a recurring window such as a day, week, or month.

Example:

• $5,000 per month for subscriptions and vendor costs
• $20,000 per month for data, inference, and compute operations

These limits reset when the period resets. Unused capacity does not roll over.

Lifetime Limits#

Cap total activity over the life of the agent.

Example:

• an experimental agent can manage up to $1,000 total before human review is required

This is useful for trials, contractors, or short-lived automations.

Maximum Number of Actions Per Period#

Cap how many actions the agent can take inside the current period window.

This matters because spend limits and action-count limits solve different problems:

• a dollar cap controls value
• an action-count cap controls frequency

Example:

• at most 20 actions per day
• at most 2 swaps or rebalances inside the active period

This is useful when you want to prevent spammy loops, overactive automations, or excessive trading frequency even when the dollar amounts are small.

Fail on Missing Price#

Some controls depend on reliable price data.

If this safeguard is enabled, Hightop blocks the action when it cannot establish the price information needed to evaluate the configured rules.

This matters most for:

• value-based spending limits
• swap and rebalance safety checks
• debt and collateral actions that depend on valuation

How Rules Stack#

Hightop evaluates controls in layers:

1. account-wide rules define the outer ceiling for delegated agent activity on the account
2. agent-specific rules narrow that ceiling for one agent
3. path-specific rules apply to the exact payment path or action object being used

The most restrictive applicable rule wins.

Example:

• account-wide payment cap: $10,000 per transaction
• operations agent cap: $2,500 per transaction
• recurring payment cap for one vendor: $1,000 per transaction

Result:

• that payment is capped at $1,000, because that is the tightest rule in the stack

This is what lets Hightop combine automation with strict controls. No single setting gets the final say on its own.

Operational Limits#

Period Window#

Period-based limits need a recurring window.

At the account-wide level, Hightop defines the period length that agent-wide controls use. That is the window used for settings like:

• per-period spend caps
• maximum number of actions per period
• swap or rebalance frequency caps

Examples:

• 1 day
• 1 week
• 1 month

When the period resets, those counters reset too.

This is an account-wide setting, not a separate per-agent one. All of your agents share the same period window. If you set it to one week, every agent's per-period counters reset on that same weekly cycle. Different agents can have different caps inside that shared window, but the reset timing is the same.

Cooldowns#

Require waiting time between actions.

Cooldowns are useful when you want to slow down rapid-fire behavior, prevent repeated mistakes, or reduce the blast radius of a bad loop.

Cooldowns are tracked at different layers. An agent-level cooldown is separate from recurring-payment cooldowns and one-off-payment creation or payment cooldowns, so one path hitting a cooldown does not automatically freeze every other path.

Timing Controls#

Timing rules let you control when an agent becomes active and when its access ends.

An agent can have both:

• an activation delay
• an expiry window

That is useful when:

• a sensitive permission change should wait behind a review window
• a contractor only needs access for a quarter
• a temporary strategy should expire automatically
• you want every agent to require periodic review

The underlying timing model is intentionally conservative:

• the account defines the default timing envelope
• a specific agent can be made to wait longer before activation
• a specific agent can be given a shorter active lifetime

That means agent-specific timing can narrow the account-wide timing defaults, not silently weaken them.

Asset and Venue Restrictions#

You do not have to let every agent touch every balance.

You can scope an agent to:

• specific assets only
• stablecoins only
• a defined list of supported venues or markets
• approved yield opportunities only

This matters because an agent that is good at paying vendors is not automatically the same kind of agent you want moving long-term balances or managing debt.

These restrictions are not cosmetic. If an action touches an asset or venue outside the allowed set, the action fails.

Swap and Rebalance Controls#

For agents that can buy, sell, or rebalance, amount limits are only part of the picture.

The control model also includes:

Maximum Slippage#

Cap how far execution is allowed to drift from the expected price.

This protects against:

• poor execution during volatility
• manipulated routes
• trades that clear at a meaningfully worse price than intended

Maximum Swaps or Rebalances Per Period#

Cap how often the agent can make trade-like moves inside the current period window.

This is useful when you want:

• a research or operations agent to rebalance occasionally, not constantly
• an investment policy to move deliberately instead of thrashing

Require Priceable Assets#

Require Hightop to have the pricing information needed to evaluate the move safely.

This prevents the agent from trading assets when the system cannot establish a trustworthy value for what is going in or out.

Approved Yield Opportunities Only#

Hightop already maintains a curated list of supported yield protocols. This setting lets you narrow an agent further so it can only use the subset of those approved opportunities that you choose.

This is useful when you want automation, but only inside your own reviewed shortlist rather than across every Earn venue Hightop supports.

Payment Paths and Recipient Rules#

For payment actions, recipient rules matter as much as budget rules.

An agent may be allowed to send payments, but still be limited to:

• Recurring Payments for approved repeat vendors
• One-Off Payments for controlled ad hoc payouts
• Trusted Transfers for your own highest-trust destinations

This keeps the system from collapsing into "the agent can pay anyone."

There is also an important narrower filter for recurring vendors:

• the account can approve many recurring vendors overall
• a specific agent can still be limited to only a smaller subset of those approved vendors

That is useful when one agent should only pay the vendors relevant to its own job, even if the account as a whole has many more approved payment relationships.

For example, your account might approve 10 recurring vendors across data, inference, and compute providers. Your research agent can be limited to only the 3 data-related vendors, while your operations agent sees only the 4 compute providers. Neither agent can pay the other's vendors.

The easiest way to reason about payment rules is by path:

Recurring Payments#

The action must satisfy:

• account-wide rules
• the agent's own rules
• any narrower recurring-vendor subset for that agent
• the recurring relationship's rules

One-Off Payments#

Creation must satisfy:

• account-wide rules
• the agent's own rules
• the account's one-off-payment creation settings, including create toggles, caps, cooldowns, asset restrictions, and amount/delay rules

Execution must satisfy:

• account-wide rules
• the agent's own rules
• the account's one-off-payment payment settings, including pay toggles, caps, cooldowns, and asset restrictions
• the specific one-off payment's own timing and claim/payment settings

Trusted Transfers#

Trusted destinations are different. They are governed by the trusted list, not by recurring payment rules.

For agent-initiated trusted transfers, the action must satisfy:

• account-wide rules
• the agent's own rules
• the destination being active in the trusted list

Trusted Transfers bypass the normal recurring-payment and one-off recipient mechanics, but agent-initiated transfers do not bypass the higher-level agent rules. Control-wallet-initiated transfers are different: once a trusted destination is already active, the control wallet can send funds there immediately without those delegated agent caps.

Validation Before and After an Action#

The control model works in two stages.

Before the action#

Hightop checks:

• is the agent active
• does it have the right permission
• is the asset allowed
• is the venue allowed
• is the recipient valid for this path
• has the cooldown elapsed

After the action#

Hightop checks whether the result stayed within the configured boundaries, such as:

• per-transaction cap
• period cap
• lifetime cap

If a required check fails, the action does not go through.

These checks and the action itself execute atomically. If a required condition fails, Hightop does not partially complete the action and "sort it out later."

What This Page Does Not Cover#

This page explains the rules layer.

It does not explain:

• how to create an agent in the app
• how recurring payments work in detail
• how one-off payments work in detail
• how trusted destinations work in detail

For those, read:

• AI Agents
• Recurring Payments
• One-Off Payments
• Trusted Transfers
• If an Agent Goes Off-Script