> For the complete documentation index, see [llms.txt](https://dataipo.gitbook.io/dataipo-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-9-agent-native.md).
# Chapter 9 — Agent-Native
Agents take part in capital workflows under verifiable identity, minimal permissions, explicit limits, and revocable authorization. Control of capital stays with authorized humans, institutions, and formal accounts.
## 9.1 Principals, agents, and accounts
The agent action chain runs Principal → Authorized Agent → SimpleChain verification → execution systems → Wallet / Account controllers. The principal defines goals and grants authority; the agent works within scope; SimpleChain verifies state, policy, credentials, and authorization; wallets, custodians, and formal accounts perform whatever needs a signature or funds authority.
Permission and funds-control boundaries among the principal, the authorized agent, SimpleChain protocol verification, and wallet accounts
*Figure 4 Agent-native authorization and funds boundaries*
## 9.2 AgentAuthorization
| Field | Meaning | Control requirement |
| ----------------- | ---------------------------------------------------------------------- | --------------------------------------------------- |
| principal | The party granting authority and bearing responsibility | Must be verifiable and entitled to grant |
| agent | The agent identity, running instance, or service | Bound to credential, version, execution environment |
| allowed\_actions | Permitted read, analyze, suggest, prepare, submit actions | Unlisted actions denied by default |
| resource\_scope | Covered assets, accounts, policies, data domains, tasks | No generalization to other objects |
| limits | Amount, count, frequency, risk, geography, time limits | Re-verified before every execution |
| validity | Effective and expiry times, session and nonce rules | Expires automatically |
| human\_review | Conditions requiring human review or dual approval | Cannot be skipped by the agent |
| signature\_policy | Which human, institutional, wallet, or account signatures are required | Submission and signing powers separated |
| revocation | Revoking party, method, effective time, propagation scope | Blocks new actions; flags in-flight tasks |
## 9.3 Action tiers
| Tier | May be authorized | Never authorized by default |
| ------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Read | Approved asset states, evidence summaries, policies, receipts | Cross-tenant, cross-purpose, or privacy-bypassing reads |
| Analyze | Computation, ranking, valuation, risk identification, difference checks | Overwriting model inference onto formal facts |
| Suggest | Structuring, approval, disclosure, trading, disposal suggestions | Passing suggestions off as legal, audit, or licensed conclusions |
| Prepare | Workflows, PCTs, forms, instructions awaiting signature, evidence packages | Removing required evidence or lowering approval requirements |
| Submit | Approved instructions within limits, windows, and named systems | Out-of-scope submission, batch privilege growth, repeat execution |
| Sign and fund | Controlled signing flows only where an external formal mechanism explicitly allows | Holding or deriving user keys; bypassing wallet and custody controls |
## 9.4 The Agent-Native Capital Router and interfaces
The Agent-Native Capital Router is the controlled routing layer connecting AICOS, SimpleChain, external chains, licensed institutions, custody, banking, payment, and settlement networks. It runs a staged protocol of prepare / approve / submit / confirm; a state or policy change at any stage forces later stages to re-verify.
Agent interfaces come in seven kinds: Query (by Asset ID, version, time, permission), Subscribe (state dimensions, evidence revocation, policy updates, settlement and risk events), Evaluate (submit objects and credentials to CaaS for a versioned rule decision), Prepare (authorization requests, PCTEnvelopes, settlement preconditions), Submit (only with approval, signatures, and validity all present, under an idempotency key), Receipt (execution and state-update receipts), Audit (export the evidence, models, policies, approvals, signatures, and results behind a decision or execution). Analysis and execution run on separate ports, isolated by EIP-712 signatures.
## 9.5 The task state machine and revocation propagation
An agent task has a state machine independent of the business outcome: requested → scoped → prepared → approved → submitted → confirmed, with rejected, expired, revoked, failed, and disputed as auditable branches or terminals. Every transition binds the task version, authorization reference, state version, policy version, responsible party, time, and result, which keeps a model session or tool call from being mistaken for business completion. Revocation propagates to unfinished tasks and their derived credentials, sessions, and pending materials; effects already produced externally are handled through SettlementReceipt, LifecycleEvent, compensation, or dispute, and the original task and result stay in the audit chain.
## 9.6 Model and tool security
Agent calls must guard against prompt injection, tool privilege escalation, data exfiltration, identity confusion, task replay, model drift, and supply-chain risk. High-risk tools accept structured parameters only and enforce server-side authorization; model output can trigger only explicitly defined actions; sensitive data enters model context only for a stated purpose, in minimal scope, under authorization. Every agent action records agent\_id, model\_or\_runtime\_version, tool, input\_refs, policy\_refs, authorization\_ref, output\_hash, human\_review, execution\_ref, and result. When an agent cannot verify any precondition, the system refuses to execute; irreversible or major capital actions carry explicit human approval, dual control, limits, cooling-off periods, or external signatures.
> **Agent claim**
>
> Agents can already pay; SimpleChain gives them a balance sheet. The permissions to read, analyze, prepare, and submit are written at the protocol layer, and fund disposal and signing stay with humans and formal accounts.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-9-agent-native.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
