Access, approval, and accountability
What May an AI Agent Read and Do? Write Access and Approval First
Once an Agent connects to a system, permissions are no longer a login setting. Define readable data, allowed tools, and human-approval gates before integration.
After an AI Agent connects to CRM or a back office, the real worry is rarely whether it can answer. It is whether it will see the wrong data or take an action nobody approved. That concern is fair. People at least inherit access from a role. An Agent that can query, create records, and send notices acts quickly and does not pause to consider consequences. If launch only means “try it,” teams later cannot say what it read, what it changed, or who allowed it. Access and approval are the condition for entering a live workflow, not a security patch added afterward.
Separate what it can see from what it can do
For an Agent, login is not enough. Reading covers which customers, orders, files, and conversations may enter context. Actions cover search, drafting, field updates, notices, or handoff. Readable does not mean writable. One switch for both usually slides toward doing everything.
Read scope should not be the whole database. A service Agent may only need order status, last shipment, and contact details. Cost, discount policy, and HR data often add risk without helping the first workflow.
One operations team wanted the Agent to “see everything so it would be smarter.” The work only needed a few operational fields. Narrowing the scope made the pilot reviewable.
- Read: tables, fields, document sets, and time range
- Act: search, summarize, create, update, notify, route
- Forbid: binding prices, payment flags, bulk export, deletion, and overwriting critical states
Put approval before anything reaches the outside world
Reviewing logs after the fact is too late if a customer already received the message. Internal drafting can be automatic; customer-visible, financial, or fulfillment changes should wait.
Reviewers need the original input, cited records, the proposed message or field writes, and uncertainties. They are not there to admire the prose. They decide whether the step may represent the company.
Approvers should match existing authority. An Agent does not create a new power structure; it encodes the one you already have.
Give the Agent its own identity; keep accountability with people
Do not let an Agent use a colleague’s personal API login. Shared accounts scramble audit trails and break when that person changes role. Use a dedicated identity with least privilege and a kill switch.
A dedicated identity does not remove responsibility. Logs should show the Agent proposed an action and which user approved it. The customer-facing name remains the company and that approver.
AgentTech designs identity, roles, data scope, and tool lists together, and keeps an emergency stop for one workflow without shutting down the rest of the product.
Permissions expire; so do documents and rules
Revisit readable data and allowed actions after the pilot and each expansion. Extra access left in place becomes harder to remove.
Knowledge sources need owners and validity dates. Confident answers from stale price lists are still wrong. Access design includes which approved sources may be cited.
Keep the first version narrow, but write it as acceptance criteria
A one-page table is often enough: the job, what it may read, what it may do, what waits for a person, and which log fields are kept.
Test with complete data, missing data, out-of-scope requests, and high-risk asks. Those cases become regression checks when prompts change.
If a custom system already exists, align Agent roles with current ones instead of inventing a parallel permission language.
Service for this topic
AI Agent system integration
AI AGENT
Connect AI Agents to custom systems, apps, data, and third-party tools, with explicit data access, allowed actions, human approval, logs, and exception handling.