AI Agents Need Delegated Authority, Not Raw Credentials

Useful agents eventually cross the same boundary: they stop only answering questions and start acting in real systems. Long-lived credentials are the wrong boundary for model-driven action.

They read email. Create calendar events. Search documents. Open GitHub issues. Post to Slack. Call internal APIs. Trigger operational workflows.

The easiest way to build that today is also the pattern that should make us uncomfortable: place OAuth refresh tokens, API keys, bot tokens, and service credentials close to the agent runtime, then trust the surrounding tool code not to misuse them.

That is a weak boundary.

Agent runtimes are extensible. Plugins evolve. Tool calls are model-driven. External content can contain hostile instructions. Logs, config files, shell environments, local auth profiles, and debug traces are all places where secrets eventually leak or become hard to reason about.

What We Are Building

AgentHiFive is an open-source authority delegation layer for AI agents.

The basic rule is simple: the agent runtime should not own long-lived provider credentials.

Instead, users and workspace owners connect accounts once, define policies, and let agents request specific actions through a controlled execution layer. That layer can check method and endpoint allowlists, enforce read/write boundaries, require step-up approval, apply rate limits, record audit logs, and revoke access without hunting through every agent host, plugin, or local config file.

AgentHiFive is not trying to replace agent runtimes. It is designed to sit between runtimes and external services. The runtime still owns prompts, planning, UX, memory, and tool presentation. AgentHiFive owns the sensitive boundary where delegated authority becomes external action.

Why Raw Credentials Are A Bad Default

Raw credentials collapse several different concerns into one object. A token often answers all of these questions at once:

• Which account can the agent access?
• Which API endpoints can it call?
• Which actions require human approval?
• How much can it do before rate limits or policy stop it?
• What happened, when, and under which user instruction?

When the answer is "whatever this token allows," the runtime has to reinvent policy, approval, logging, and revocation around every connector. That is expensive work, and it tends to drift across plugins.

What Exists Today

This is not only a whiteboard architecture.

The open-source repo includes the core platform, a TypeScript SDK, an OpenClaw integration, an MCP server, self-hosting docs, and integration-testing paths. The OpenClaw plugin gives agents vault tools for brokered execution, capability requests, approval waiting, connection listing, revocation, and downloads. The MCP server exposes similar vault capabilities to MCP-compatible clients.

The current OpenClaw integration is our reference path because it makes the problem visible: agent hosts often accumulate local auth profiles, provider API keys, channel tokens, and OAuth sessions. AgentHiFive moves those provider credentials into a vault and leaves the agent runtime with narrower session credentials and opaque connection references.

What This Does Not Solve

AgentHiFive is not a complete sandbox for all agent behavior.

It does not eliminate prompt injection. It does not prove that every connector is safe. It does not replace provider-side authorization. It does not make arbitrary code execution harmless.

The narrower claim is more useful: for actions routed through AgentHiFive, there is a concrete boundary where requests can be inspected, denied, approved, replayed, logged, and revoked.

That boundary is small enough to review, test, and improve.

Where We Need Collaborators

• Runtime adapters: OpenClaw, MCP clients, Python agents, TypeScript frameworks, local coding agents, and self-hosted assistants.
• MCP semantics: approval-required responses, pause and resume behavior, retries, and denied-action explanations.
• Connector coverage: action templates for mail, calendars, documents, chat, ticketing, source control, and internal APIs.
• Security review: threat-model gaps, overclaims, policy bypass cases, SSRF-style risks, token lifetimes, replay semantics, and audit integrity.
• Self-hosting and onboarding: making the project easy to run, test, and understand in one sitting.

Get Involved

The most useful first contribution is not a grand redesign. It is a bounded test, adapter sketch, doc fix, policy review, or connector example that makes the authority boundary easier to trust.

If you maintain an agent runtime, build MCP servers, write connectors, operate self-hosted AI tools, or think about LLM security, we would like your blunt feedback.

Try the OpenClaw path, inspect the MCP server, review the approval semantics, or pick one help-wanted issue. The question we want to answer with other builders is simple: where should delegated authority live in the agent stack?