An AI agent may begin as a harmless assistant that reads a knowledge base. A few successful demos later, it can search customer records, open tickets and update an internal system. The risk changes faster than the pilot plan: permission to call a tool does not necessarily control which records or fields that tool returns.
For Indian product and IT teams, the useful question is not simply whether an agent has access. It is whether every request is limited by user, data object, action and time. This checklist helps a team test those boundaries before connecting a pilot to real business data.
Why tool access and data access are different
Traditional access control often answers a broad question: may this identity use the CRM connector or query the database? An agent can still compose an unexpected query after that check. If the connector holds a powerful credential, it may return more rows, columns or files than the person behind the request should see.
A September 22 AWS open-source announcement illustrates this distinction through object-level policy enforcement for agent tools. The project is one implementation, not a universal standard or automatic compliance solution. Its practical lesson is broader: filter and mask data before it enters the model context, because an output guardrail runs after retrieval.
This is a different job from maintaining a software access inventory. The inventory tells you who or what can reach a system. An agent permission review also asks what each tool call can see and do inside it.
Map one pilot as an end-to-end path
Start with one real workflow, not a company-wide agent policy. Draw the path from the employee request to the model, orchestrator, tool, credential and data source. Mark where identity is checked, where rows or fields are filtered, where a write is approved and where the action is logged.
Illustrative example: a support agent is asked to summarise unresolved tickets for the Mumbai service team. A safe path should bind the request to that employee, return only assigned-region tickets, exclude payment details, allow a draft summary and prevent the agent from closing tickets. “Read access to support” is too vague to prove any of those boundaries.
Use four boundaries instead of one broad role
A practical review separates permissions into four dimensions. This prevents a role labelled “reader” from looking safer than its actual reach.
| Boundary | Question to test | Evidence to save |
|---|---|---|
| Identity | Is the agent acting as itself or on behalf of a named user? | Identity and owner record |
| Data | Which tenants, rows, fields, files or storage prefixes can return? | Allowed and denied test results |
| Action | Can it read, draft, export, edit, delete or approve? | Tool manifest and approval rule |
| Time | When do tokens and elevated permissions expire? | Expiry and revocation test |
Test combinations as well as individual tools. Email access and CRM access may each appear reasonable, while their combination lets an agent join private conversations to customer profiles. The effective capability is the chain, not the least alarming permission in it.
Run three tests before using live customer data
- Allowed request: confirm the agent completes its narrow business task and the log records the user, policy, tool and result.
- Blocked request: ask for another region, customer, restricted field or disallowed action. The tool or data layer should refuse it before returning the data.
- Revocation request: disable the agent or remove elevation during a test, then confirm cached tokens and queued work cannot continue.
Use synthetic or redacted records first. A polished answer is not evidence of a secure boundary. The team needs the denied result, relevant log entry and recovery outcome. If customer conversations are part of the pilot, first identify the hidden data already sitting in support inboxes; otherwise, a “ticket summary” test may expose attachments or identifiers that the pilot owner never considered.
Decide whether to pilot, limit or pause
Proceed with a limited pilot only when the allowed task works, the forbidden task fails at the source boundary, every high-impact write needs an explicit approval and revocation has been demonstrated. Limit the pilot to synthetic data when filtering exists but ownership or logging is incomplete.
Pause when a shared administrator credential powers the tool, when policy lives only in a prompt, when the agent receives unrestricted data and redacts it later, or when nobody can stop queued actions. Those are architecture gaps, not documentation gaps.
Keep a small evidence pack
For each pilot, retain the workflow diagram, agent owner, purpose, approved tools, effective scopes, sample allow-and-deny results, approval record, log location, token lifetime and last revocation-test date. Add a change rule: a new data source, write action, user group or external vendor triggers another review.
This evidence pack complements a general AI-use policy. It gives engineering, operations and management the same concrete record, without pretending that a checklist replaces security testing or legal assessment.
Conclusion
AI agent tool permissions are ready for a live pilot only when the team can prove what the agent cannot retrieve or change. Map one workflow, enforce limits close to each data source, test a denial and practise revocation. If any of those checks depends on the model behaving politely, keep the pilot away from live customer data.
