AI Agents with Tools: Why "Can Read" and "Can Write" Are Worlds Apart
The article examines the critical gap between read-only and write capabilities when AI agents access tools, showing how authorization boundaries blur, referencing NIST and Chinese standards, and proposing a three-layer framework — action, object, and result boundaries — to evaluate agent permissions and their security implications.
Someone asks an agent to summarize a public policy document; seconds later they get the summary. The next request: "Also update this information in the shared ledger." The chat interface looks identical, but the backend action shifts from reading to modifying a record that others will see.
One "Connect Tools" Button Hides Several Different Actions
Querying files, aggregating data, changing fields, sending notifications — all are summarized in product pitches as "calling tools." For the user, however, they are not the same. Misreading a passage can usually be corrected by checking the source; altering a shared record may affect the next person's judgment; sending to an external channel expands the impact further.
The U.S. National Institute of Standards and Technology (NIST), in its public discussion on tool use in agent systems, explicitly distinguishes read-only , constrained write , and write permissions, and flags whether an action leaves a persistent effect and whether it is reversible. This is not a Chinese mandate, but it provides a clear analytical lens: tools with the same name can produce completely different consequences.
"Human Confirmed" Does Not Mean Every Step Was Seen
Imagine a generic office workflow: the agent extracts a date from multiple documents, then writes that date into a shared ledger. The confirmation prompt the human sees may only say "Update ledger?" If the extraction basis, target field, and original value are not shown together, clicking confirm does not prove the change was fully understood.
The point is not to pop up a confirmation for every tiny action — too many confirmations breed habitual clicking. What matters more is: at the step that requires human judgment, are the basis, the exact change, and the affected parties made clear? This observation is based on public materials, not a description of any specific system's runtime behavior.
Standard Projects Turn Attention to the Full Data-Processing Lifecycle
The Data Security Technology — Agent Data Processing Security Requirements published on the National Standard Information Public Service Platform is currently a recommended national standard project , not yet an implemented standard. Its scope lists processing-rule mapping and authorization control, data retrieval and extraction, processing and memory, sharing and collaboration, deletion and retention, and monitoring and audit.
The Cyberspace Administration of China's Implementation Opinions on Standardized Application and Innovative Development of Agents also states that agent operations must not exceed the user's authorized scope, and includes permission management and behavior control in security-capability research directions. Together these public documents signal a shift: discussing agent security cannot stop at what the agent says; we must also examine what capabilities it has been granted and what those capabilities ultimately modify.
One Operation Has at Least Three Layers of Boundaries
Take "update shared ledger" as an example. The first layer is the action boundary : can it only read, or can it create, overwrite, delete? The second layer is the object boundary : can it touch the whole table, or only the fields relevant to the current task? The third layer is the result boundary : is the change traceable and verifiable, and can it be rolled back if something goes wrong?
These three layers are an observation framework proposed in this article, not a direct classification from the cited documents. Their value lies in breaking a vague "authorized" into concrete dimensions so that users and product designers can talk about the same specific thing.
The more an agent resembles a capable colleague, the easier it is to apply chat-assistant intuition. But once it starts modifying shared data, a single click in the UI is no longer just a question. What deserves ongoing attention is whether products can hand back the clarity of action, object, and result to the people who are truly accountable.
Sources and Basis
• National Standard Information Public Service Platform: Data Security Technology — Agent Data Processing Security Requirements national standard project. Used to verify project status and intended coverage; not yet an implemented standard. • Central Cyberspace Affairs Commission: Implementation Opinions on Standardized Application and Innovative Development of Agents . Used to verify policy statements on authorization scope, permission management, and behavior control. • NIST: Lessons Learned from the Consortium: Tool Use in Agent Systems . Used to illustrate tool-permission and reversibility analysis dimensions; not a Chinese regulatory basis. The office scenarios and "three-layer boundaries" in this article are hypothetical constructs and the author's synthesis based on public materials.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Frontline Investigation
Daily curates a variety of tech resources, tools, tips, and news (5G, big data, cloud computing, AI), aiming to become a go-to popular science encyclopedia for everyone.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
