Access control
How roles and permissions decide who can use AI and which systems, records, fields, or actions are available.
Identity and access
AI systems need roles, limits, approval, and evidence.
Identity and access are the rules that decide who can use an AI system, what the AI can see, which tools it can call, what actions it can prepare, and which steps require approval. Without clear access control, useful AI integration can quickly become risky infrastructure.
What this section explains
These guides cover the permission layer around AI integration: RBAC, least privilege, service accounts, credentials, approval gates, and audit trails.
Least privilege
Why AI agents, connectors, tools, and workflows should receive only the minimum access required.
Service accounts
How AI integrations use credentials, tokens, keys, and system identities to reach approved tools.
Approval gates
Where human, policy, or workflow approval should sit before sensitive actions happen.
Audit trails
How requests, outputs, tool calls, approvals, errors, and system changes can be reviewed later.
Identity and access article list
This section contains five launch articles. Build these before treating the section as complete.
Start here
Reading order
AI Access Control and RBAC
Learn how role-based access control applies when AI can retrieve documents, use tools, read records, or prepare actions.
Minimum accessLeast Privilege for AI Agents
Understand why AI agents, connectors, and tools should only receive the narrow access required for the approved task.
System identityService Accounts, Credentials, and Secrets
Learn how service accounts, API keys, tokens, OAuth connections, and secrets should be protected and revocable.
Review pointsApproval Gates in AI-Connected Systems
See where human or policy review should sit before AI-assisted work changes records, sends messages, or triggers workflows.
EvidenceAudit Trails for AI Integrations
Understand what evidence should follow AI requests, source retrieval, outputs, tool calls, approvals, and changes.
Recommended path
Start with RBAC, then least privilege, service accounts, approval gates, and audit trails. That order follows the path from who may access AI to what evidence remains after use.
How identity and access fit into AI integration
Access control is not a side issue. It sits between users, AI models, connectors, data sources, tools, actions, and audit records.
1
User or system
A person, workflow, application, trigger, or AI agent starts the request.
2
Identity check
The system checks the user, role, service account, connector identity, or workflow authority.
3
Access boundary
Permissions decide which data, tools, records, fields, and actions are allowed.
4
Review and evidence
Approval gates, logs, audit trails, and incident records preserve accountability.
Governance reminder: AI can support work, but the organization still needs to know who
authorized access, what the AI could do, and who remains responsible for important actions.
Why identity matters more when AI is integrated
A standalone AI chat may answer questions, but an integrated AI system can retrieve internal documents, query business records, call APIs, use connectors, create drafts, update fields, or trigger workflows. That means the system needs clear identity and access rules.
The access question is not only “Can a human user log in?” It is also “Which identity does the AI use?” and “What can that identity do?” An AI integration may act through a user identity, a service account, a connector identity, an API key, a workflow identity, or a platform-managed authorization.
| Identity type | Plain meaning | Important question |
|---|---|---|
| User identity | The AI acts based on the current user’s role or permissions. | Does the AI respect what this user can actually see or do? |
| Service account | The integration uses a system account created for the AI or connector. | Is the account limited, owned, protected, and revocable? |
| Connector identity | A connected app or platform authorization reaches another system. | What systems, records, fields, and actions can the connector access? |
| Workflow identity | An automation or event-driven process acts under a defined workflow role. | Can logs show which workflow triggered the action? |
| Admin identity | A high-privilege account can change settings, access broad data, or manage systems. | Should AI ever use this level of access? Usually this needs very strong controls. |
Access questions before connecting AI
- Who can use the AI feature?
- Which user, role, service account, or connector identity does the AI use?
- What can the AI read?
- What can the AI write, send, update, approve, or trigger?
- Which records, fields, documents, systems, or actions are out of scope?
- Which actions require human approval?
- What gets logged?
- How can access be revoked, reduced, or paused?
How this section connects to the rest of the site
Identity and access rules support every other part of AI integration. Data systems need permission systems need permission boundaries. APIs and connectors need credentials and scopes. Model platforms need release and routing controls. RAG systems need knowledge access control. Monitoring needs traceable identities. Security and compliance review need evidence.
Data Systems
Access rules decide which data sources AI can retrieve or summarize.
APIs and Connectors
Connector identities and credentials define what AI can reach or trigger.
RAG and Knowledge
Knowledge retrieval should respect document permissions and source sensitivity.
Security and Compliance
Security review depends on least privilege, credential protection, and audit evidence.
Educational limitation
This section provides general educational information about identity and access for AI integration. It is not legal, financial, medical, engineering, safety, cybersecurity, procurement, compliance, privacy, or professional advice. It does not provide instructions for bypassing controls, exploiting systems, unauthorized access, or unsafe automation. Use qualified review before connecting AI to sensitive data, regulated systems, production infrastructure, customer records, financial processes, safety systems, or other high-consequence environments.