How to give an AI agent tools without giving it unlimited authority

An AI agent needs enough capability to complete its task and no ambient authority beyond that task. The practical design separates six stages: discover a capability, read approved context, draft an action, obtain approval where required, execute a stored proposal and record the result.

A prompt that says “never delete records” is useful guidance. It is not an authorization control. The connector, runtime and policy layer must make prohibited actions unavailable or refuse them deterministically.

Start with a capability contract

Define each tool as a small contract:

“Email access” is not a capability contract. It mixes reading, sending, deleting, account selection and data scope. Smaller tools make both model behavior and security review easier to reason about.

Separate discovery from execution

An agent can discover that a connector supports an operation without receiving authority to run it. This separation matters when tool catalogs are large or generated dynamically.

In Skybridge, connector references can be loaded on demand. The agent learns the supported endpoint shape when needed, while the runtime still decides whether the connected account and operation are permitted. Documentation is knowledge, not permission.

This also keeps context smaller. Injecting every connector endpoint into every model turn increases cost and gives the model irrelevant choices. On-demand discovery narrows the decision while the enforcement layer remains constant.

Split read, draft and write authority

Reading several accounts can be safe and useful for an overview. Writing from an unspecified account creates a visible commitment. The two operations should not inherit the same ambiguity rule.

Skybridge can fan out an unqualified read across connected accounts and label each result with its source. A write from an ambiguous account is refused until the account is named. That decision lives in code because an unattended automation cannot reliably stop and ask a user.

Drafting belongs between read and write. An agent may produce a proposed email, CRM update or calendar event without gaining permission to commit it. The proposal becomes a typed object that policy can inspect.

Put deterministic policy before the connector

Each action should resolve to one of three outcomes:

• permitted and executable within the contract;
• permitted only after an authorized approval; or
• prohibited for this system.

The policy should inspect the real tool, method, account and arguments. A generic HTTP client or Model Context Protocol server can widen the action surface, so the network and endpoint boundary needs equal attention.

The OWASP guidance for large language model applications treats excessive agency as a distinct risk. The useful response is to reduce tools, permissions and autonomy to the minimum required by the use case, then add human authorization for high-impact actions. See the OWASP project for the current taxonomy.

Bind approval to the exact proposal

Approval must cover a frozen payload. Store the tool name, destination account, arguments and material content before requesting a decision. If the draft changes, create a new proposal and require a new approval.

Execution should consume the stored proposal once. Do not ask the model to remember or recreate the approved action after the reviewer clicks. A second model call can change a recipient or parameter without malicious intent.

Skybridge records approval and connector execution separately. That preserves a crucial fact: a human can validly authorize an action that later fails at the destination. Recovery depends on knowing both events.

Treat retrieved content as data

Tool authority also limits prompt injection. An email, document or web page may contain instructions addressed to the model. Retrieved content should be marked as untrusted data and placed below the system and owner instruction layers.

Instruction hierarchy reduces confusion, but it cannot carry the whole defense. A malicious document has less impact when the agent cannot add tools, switch accounts or bypass approval. The authority design limits the blast radius when language-level defenses fail.

Record enough evidence to reconstruct the decision

For every consequential tool call, keep the business request, selected tool, account label, arguments or protected digest, policy result, approval record, execution result and correlation identifier. Sensitive payloads may need redaction or shorter retention, but the evidence design should be explicit.

The record serves three people. The operator diagnoses failure. The business owner confirms what was requested. The reviewer sees whether the action stayed inside the accepted perimeter.

Test the boundaries, not only the happy path

A useful acceptance suite asks the agent to:

1. call a tool it has not been granted;
2. write through an unnamed account when several are connected;
3. change a payload after approval;
4. reuse an already consumed approval;
5. follow an instruction embedded in retrieved content;
6. exceed a result or pagination limit; and
7. act while outbound writes are disabled in development.

The expected result is a deterministic refusal or safe simulation with an observable reason. A polite model message is not enough if the connector call already left the system.

Skybridge applies authority per delivered system

Compsia defines tools, accounts, action classes, approvers and failure behavior for the exact production result. Skybridge supplies the scoped connection, approval and evidence mechanisms underneath that design. A connector's presence never means every operation is available.

This model keeps the agent useful because it can read, reason and prepare work. Business authority remains in typed tools, runtime policy and attributable decisions. Continue with the human approval state machine or the connector fitness test to specify the next layer.