AGENT01
Understand the goal and plan
Select from visible capabilities and coordinate reads, writes, and multi-step work.
Cannot claim identity or expand its scopeSECURITY & GOVERNANCE
Every agent action needsan identity, a boundary, and a traceable outcome
BailingHub defines the most an agent may discover and request. The source system still decides whether this call is allowed under the current user, tenant, role, and live rules.
Trusted identityLeast capability scopeRisk-based approvalIdempotent recoveryVisible execution trace
01AUTHORITY DOES NOT MOVE
Agents plan, the Hub governs, and the business system keeps authority
Security comes from separated responsibilities, not from hoping a model always behaves.
BAILINGHUB02
Project capabilities and govern calls
Check identity, route, risk, approval, idempotency, and invocation state, then record visible traces.
Cannot grant final business permissionBUSINESS SYSTEM03
Decide under live rules
Recheck user, tenant, role, field permission, and business state before execution.
Remains the final source of authority and record02HOW AN ACTION BECOMES VALID
No layer can be skipped between a sentence and a business write
A call must not only succeed; the system must explain why it was allowed, who approved it, and what finally happened.
01DECLARE
Declare
Expose only operations intended for agents.
02IDENTITY
Bind identity
Establish a trusted subject from the business login.
03PROJECT
Project scope
Intersect client, route, identity, and policy.
04PLAN
Select tools
Plan only with capabilities visible in this turn.
05GOVERN
Govern
Check arguments, risk, approval, and idempotency.
06AUTHORIZE
Authorize
Let the source system execute or reject under live rules.
07TRACE
Trace
Record visible steps, results, approvals, and errors.
03CONTROL MECHANISMS
Limit risk before execution and recover safely after uncertainty
Each mechanism solves a different problem. Allowlisting, approval, backend authorization, and audit are not one switch.
01TRUSTED IDENTITY
Identity comes from the business system
An agent cannot establish identity through a prompt. The business login and authorization flow confirm user, tenant, store, or other scope.
Configure business authorization and model plans separately; model allowance does not grant business permissions.- Short-lived ticket or Agent Session
- Connection changes require user action
- No password or browser cookie transfer
02CAPABILITY SCOPE
Limit what can be requested first
The business side declares operations, the Hub projects a bounded set, and the backend may still reject a visible tool.
An Origin allowlist prevents unauthorized embedding; it is not server authentication.- Exact operation IDs
- Explicit write allowlist
- Live backend permissions
03RISK & APPROVAL
Approve only the original request
Routine authorized actions may run directly. Sensitive calls freeze tool and arguments, then resume only the approved invocation.
Approved calls must still pass final backend authorization.- Risk follows capability and policy
- Changed arguments require reevaluation
- Denial or expiry stops the call
04EXECUTION INTEGRITY
An error does not prove the business action failed
A timeout or audit-write error followed by a blind retry may duplicate a refund, record, or state transition.
The source system remains the final reconciliation record.- Stable idempotency key
- Result lookup and reconciliation
- Unknown-finality stops automatic retry
05AUDIT & REVOCATION
Record verifiable steps and revoke future access
Associate entry, identity, route, tool, approval, result, and error, then revoke an individual Agent Session when needed.
View sessions by device and revoke the corresponding Agent Sessions individually.- Revocation affects future calls
- Historical evidence remains
- Visible actions and results
04RUNTIME CONTROLS
Govern the operating surface, not only one invocation
Configure shared rate limits, job admission budgets, pause control, and metrics to manage traffic and detect problems in a self-hosted instance.
Share one rate-limit ledger across replicas
With MySQL, client, chat-entry IP, admin-login, tool-provider, and per-tool limits use a shared ledger instead of independent process-local windows.
- Shared MySQL sliding windows
- Entry and tool-layer coverage
- JSONL is for local smoke tests only
Check budgets before starting new jobs
Route and client budgets use recorded tokens or costs to reject new jobs at the limit. The model-plan gateway settles actual usage asynchronously without interrupting output for billing checks; concurrent requests and late settlement may exceed the allowance.
- Route first, client fallback
- Control new job admission
- Model plans settle separately
Pause new jobs with an explicit 503 state
An administrator can activate the kill switch through the admin endpoint or a .paused file. Callers should fall back to a human queue instead of creating a retry storm.
- POST /admin/pause
- touch .paused
- Explicit paused state
Observe risk with low-cardinality metrics
Optional GET /metrics exposes queue pressure, executor liveness, approval waits, expired leases, and audit-write failures. It is disabled by default and requires a dedicated Bearer token.
- Prometheus-compatible
- Returns 404 when disabled
- No query token or admin-root token reuse
Runtime guardrails can only tighten Hub risk. They never replace the source system’s final authorization of the current user, tenant, role, and business state.
05INTEGRATION PRINCIPLES
Operate the system without taking over final authority
Connect existing services, accounts, and permissions to give agents explicit business operation entry points.
BailingHub defines the most an agent may request. The business system decides whether this call is allowed now.
Execute through business APIs
Calls explicitly declared server-side capabilities instead of clicking arbitrary pages.
Retrieve data through business APIs
Business data is returned through controlled APIs; the source system retains ownership.
Scope access per entry point
Every entry, identity, and route should retain least privilege.
Use the business login and authorization page
The SDK provides protocol methods while the business system implements the page for its login model.
Validate your real control boundary with one read and one write
Start with a low-risk query and one governed write, then verify identity, authorization, approval, outcome, and trace.