A salesperson asks AI to prepare a customer renewal. That simple request may involve CRM records, contracts and a quotation draft. If every step uses the same administrator account, the systems can show that software accessed them, but may struggle to explain whose request it was, whether that person could access the customer, or whether unfinished work should continue after a role change.
A recent signal: agents need identities too
On September 1, 2026, HashiCorp announced general availability of agentic identity capabilities in Vault Enterprise. Oracle’s September 10 introduction to Integration MCP Gateway described identity and policy controls planned for release 26.10. Together, these announcements point toward integrating agents into established access management. The guidance below is Millionasia’s design perspective, not a list of features guaranteed across platforms.
Separate three roles
The person requesting work, the agent performing it and the account accessing ERP or CRM may be different identities. An agent’s ability to sign in does not authorize it to act for everyone. Link each execution to its requester and task. Unattended schedules need a defined service identity, owner and scope, rather than an employee’s indefinitely retained login.
Make permission specific to the task
Define the department, customers, fields, permitted actions and expiry. Distinguish preparing a draft from submitting it. Backend enforcement should use the intersection of the user’s permissions, the agent’s permissions and the task scope. A prompt saying “only this customer” helps describe intent; query and write interfaces must enforce the actual boundary.
A renewal example
Imagine an equipment service company preparing a renewal. This is an illustrative scenario, not a delivered Millionasia project. The agent reads the specified customer’s contract and authorized equipment records, obtains amounts from established pricing software and prepares a draft. It gains no access to another customer and cannot independently change discounts or send commitments. Approval should identify the actual draft, recipient and amount. A subsequent change needs a fresh check, rather than reuse of a generic approval.
Design withdrawal alongside access
A cancelled case, expired approval or departing employee should also stop queued agent work. Short-lived credentials reduce exposure but do not guarantee immediate revocation. Recheck authorization before consequential operations, and account for queued jobs, caches and downstream connections. Revoking access does not undo information already sent or records already changed; those outcomes need cancellation, correction or human handling.
Keep a useful trail
Connect the task identifier, requester, agent identity, tool, granted scope, approval version and result. Keep credentials and passwords out of model conversations and ordinary logs. A useful record also tells operations staff where work stopped and who can resume it, instead of leaving them with an unexplained failure message.
Test when the agent must refuse
Start with retrieval and drafting. Test a different customer, revoked access, a price changed after approval and an account disabled while a job is queued. Verify that actions are blocked, reasons are retained and people can take over. Alongside preparation time, measure rejection of unauthorized actions and the delay before revocation takes effect.
Millionasia’s perspective: complete the delegation chain
Connecting websites, apps, knowledge bases and ERP is a starting point. Each action should also explain who requested it, how far the authorization extends and when it ends. A verifiable delegation chain lets the business expand AI responsibilities while preserving the judgment and accountability of its existing management processes.
References (2026-10-19)
Want to bring this topic into your workflow?
Millionasia can help you review data, design AI adoption points, and integrate LLMs, RAG, back-office systems, permissions, and reports into maintainable web and APP systems.
Contact Us