Requirements · AI agents
Requirements before giving an AI agent access to company systems
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Before granting access, you need a defined task and owner, dedicated low-privilege credentials, a data classification of everything reachable, approval rules, logging with retention, a tested stop procedure, and agreement on who answers for outcomes. Without these, the agent inherits the access of whoever set it up, and nobody can reconstruct what it did.
Who this is for: A security, IT or product owner who has been asked to approve an agent that will read or write in email, files, databases or business applications.
What to evaluate
Defined purpose and owner
Agents expand in scope informally unless a named person owns the task and its limits.
How to check: Write a one-page charter stating the task, permitted systems, forbidden actions and the accountable owner.
Dedicated identity
Shared or personal credentials blur accountability and over-grant access.
How to check: Provision a separate service identity per agent, scoped to specific resources and revocable independently.
Data classification of reachable content
You cannot judge exposure without knowing what the agent could read or send.
How to check: Map each connected system to its data classes and exclude those the task does not need.
Approval and escalation rules
People need to know which actions pause and who is paged when the agent is unsure.
How to check: Document action categories, approvers and response expectations, then test the flow.
Logging and retention
Investigations and audits depend on a complete record.
How to check: Confirm logs capture each tool call and are stored where the agent cannot alter them.
Stop and recovery procedure
A fast halt limits harm when something unexpected occurs.
How to check: Rehearse revoking credentials and reversing a representative action.
Legal and policy review
Personal data, confidentiality duties and sector rules may constrain what an agent may do with certain records.
How to check: Consult privacy, legal and compliance owners and record their conditions.
Comparison
| Access level | Example | Minimum controls |
|---|---|---|
| Read-only on non-sensitive content | Summarising public documentation | Dedicated identity, logging |
| Read-only on sensitive content | Reading customer tickets or contracts | Data minimisation, restricted outbound destinations, retention limits |
| Write on reversible records | Drafting entries or tagging tickets | Approval sampling, versioning for undo |
| Write or send with external effect | Emailing customers, changing payments | Mandatory approval, strict limits, incident runbook |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 7 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Defined purpose and owner | |||
| Dedicated identity | |||
| Data classification of reachable content | |||
| Approval and escalation rules | |||
| Logging and retention | |||
| Stop and recovery procedure | |||
| Legal and policy review | |||
| Total (max 21) | 0 | 0 | 0 |
Questions to ask before you commit
- Who is the accountable owner for this agent and its outcomes?
- Which exact systems, fields and actions are in scope, and which are explicitly out?
- Does the agent use its own credentials, and can we revoke them instantly?
- Which data classes can the agent read, and can it send any of them out?
- What actions require human approval, and who approves?
- Where are logs stored and who can alter them?
- How will the agent be tested before and after changes?
- What is the rollback plan for each write action?
Typical trade-offs
Wide read access for better answers versus narrow access for safety
- Upside
- Broader context improves usefulness and reduces missed information.
- Downside
- Increases the data exposed to leakage or injection; start narrow and widen on evidence.
Pilot in a sandbox first versus go straight to a small live scope
- Upside
- A sandbox contains early mistakes.
- Downside
- It may not reveal real data problems; a tightly limited live pilot yields truer feedback with careful controls.
Central approval team versus approvals by the task owner
- Upside
- Central teams apply consistent standards.
- Downside
- They lack task context and become a bottleneck.
Common mistakes
- Letting the builder's own login power the agent. Create a dedicated service identity.
- Skipping data mapping because the pilot is small. Pilots tend to become permanent.
- Treating the logs as optional. Without them you cannot investigate or defend a decision.
- Failing to define the end of life. Decide when access will be reviewed and removed.
Related questions
Who should own an AI agent inside the company?
A business owner who benefits from the task and can judge its outcomes, supported by a technical owner who maintains tools and credentials. Security and privacy functions advise and review, but accountability sits with the business owner. Record the owners in the charter and review them when people change roles. An agent with no named owner tends to accumulate access and escape review.
How often should agent access be reviewed?
Treat it like any privileged service account: review at a regular interval, when the task changes, when tools are added and when the owner leaves. Include a check that the agent still needs each permission and that logs show usage. Remove unused access promptly. More frequent review is warranted for agents with write permissions or access to sensitive data.
Do we need to tell customers or staff an agent is involved?
Often yes. Transparency expectations and legal duties vary by jurisdiction and context, and some rules require disclosure when people interact with automated systems or when automated decisions affect them. Even where not required, clear labelling builds trust and helps people correct errors. Consult legal and privacy advisers for your situation and check your regulator's guidance.
What evidence should the approver see?
A charter, a data map, the permission list, results from test scenarios including adversarial ones, the approval and escalation design, sample logs and the stop procedure. Approvers should also see a plan for monitoring and review. If any of these cannot be produced, the deployment is not ready, regardless of how well the demonstration went.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- AI Risk Management Framework — National Institute of Standards and Technology, retrieved 27 October 2026
- Artificial Intelligence — Cybersecurity and Infrastructure Security Agency, retrieved 27 October 2026
Related guides
How to choose · AI agents
How to choose an AI agent platform for business tasks
Judge an agent platform by how safely it can act, not by how clever it sounds. Check tool and permission scoping, human approval steps, logging of every action, the ability to test on realistic scenarios, failure handling, and how costs scale with task length. A narrow, well-bounded agent beats a general one that nobody can audit.
Comparison · AI agents
AI agents versus RPA versus scripted automation
Use the most deterministic tool that does the job. Scripts and API integrations suit stable, structured processes; robotic process automation helps where only a screen interface exists; agents fit variable, language-heavy work where rules cannot be fully specified. Predictability, auditability and maintenance burden usually favour simpler tools until the input genuinely varies.
Problems & fixes · AI agents
Why AI agents fail in production and how to contain it
Agents fail in recognisable ways: wrong tool choices, compounding errors across steps, endless loops, obeying instructions hidden in untrusted content, and acting with more permission than the task needs. Contain these with least-privilege credentials, approval on consequential actions, hard limits on steps and spend, isolated handling of external content, and replayable logs.
Requirements · AI for data and analytics
Data readiness requirements before adopting AI analytics
Readiness means data that is findable, documented, access-controlled, reasonably clean and owned. Before adopting AI tools, inventory sources, classify sensitivity, fix permissions, define key metrics, document tables, set quality checks and agree ownership. Skipping these steps turns every AI feature into a faster way to surface existing mess.
Requirements · Cybersecurity and IT
Foundational requirements for securing a cloud account structure
A secure cloud foundation separates environments into distinct accounts, protects the top-level identity with strong authentication, centralises identity through a single directory, turns on audit logging in a protected location and sets organisation-wide guardrails. Doing these early is far easier than retrofitting them after teams have built on a flat, shared account.
Requirements · B2B software
Collaboration platform requirements for regulated record retention
Regulated organizations need collaboration platforms that can retain and preserve messages and files for required periods, place legal holds, search across content types, export in usable formats, restrict deletion, and prove integrity through audit logs. Requirements vary by sector and jurisdiction, so confirm obligations with counsel and the regulator, then translate them into testable platform capabilities.
Requirements · AI coding tools
What an engineering policy for AI coding tools should cover
A workable policy names approved tools and plans, forbids pasting secrets or customer data, sets repository eligibility, requires normal review and testing for all code regardless of origin, defines licence and provenance handling, covers agentic tool permissions, and assigns ownership for monitoring and updates. Keep it short enough that developers actually read it.