AI governance checklist
The AI Agent Access Checklist: 9 Controls Before an Assistant Can Act
The important question about an AI assistant is changing. It is no longer only, “Can it produce a useful answer?” Teams also need to ask, “What can it see, what can it change, and who is accountable when it acts?”
That shift is becoming visible in current product and governance discussions. OpenAI's July 9 announcement describes an agent that can work across apps and files, continue multi-step projects for hours, and pause for guidance or approval on important actions. IBM's July 2 agent-control release emphasizes access visibility, runtime policies, credential health, scheduling, and operational traces. A July 17 PwC report similarly argues for verified identity, defined roles, task-specific permissions, auditable records, and clear limits on autonomous action.
Those developments do not mean every organization should rush to grant broad access. They mean access design is becoming part of day-to-day operations. Before an assistant can send, update, schedule, approve, or change anything, use this checklist to define the boundary.
1. Name one accountable human owner
Every action-taking assistant needs a named owner who can explain its purpose, approve changes to its scope, review incidents, and decide when it should be paused. “The operations team” is not specific enough. Ownership should point to a role and, in practice, to a person currently performing that role.
For a broader systems view, review the ServingIntel integrated operations platform.
The owner does not have to watch every action. The owner does need authority to change the workflow and a clear relationship with the people who control the connected systems. If no one can answer who is accountable, the assistant is not ready for production access.
Record the owner, backup owner, review date, and escalation contact in the workflow documentation.
2. Write a one-sentence purpose and a stop list
Define the assistant's job in one sentence. A useful purpose is narrow enough to test: “Draft a weekly support summary from approved ticket fields” is clearer than “Help the support team.”
Then write what the assistant must not do. The stop list might prohibit changing account permissions, viewing payment details, handling resident or employee records, committing a refund, contacting a customer without review, or interpreting a policy exception.
For neutral background and operating context, see NIST AI Risk Management Framework.
The purpose creates the allowed lane. The stop list marks the edge of that lane. Both are needed because a positive instruction rarely captures every consequential action that should remain human-led.
3. Give the assistant its own identity
Do not let an assistant operate through an unidentified shared login or a human account that hides which actions were automated. A distinct machine identity makes it easier to assign permissions, trace activity, rotate access, and disable the assistant without interrupting a person.
PwC's July 17 governance report recommends a verified identity and defined role for each agent. A separate identity also improves incident review: the team can distinguish what a person did from what the assistant did on the person's behalf.
If a connected system cannot represent the assistant separately, document that limitation and compensate with tighter approvals and more detailed logging.
Related infrastructure planning is available in ServingIntel POS hardware guidance.
4. Start with the least data and capability required
Access should match the one-sentence purpose. If the assistant only needs to summarize resolved support tickets, it may not need customer billing records, deletion rights, administrative settings, or access to every queue.
Review data access and action access separately. Reading a schedule is different from changing it. Drafting a response is different from sending it. Preparing a proposed record update is different from writing directly to the system of record.
Begin with read-only access when possible. Add a write capability only after the team has tested the read, reasoning, and proposed action with real examples.
5. Keep secrets out of the assistant's working context
An assistant may need permission to use a connected system, but that does not mean it needs to see the password, API key, or long-lived credential behind the connection. A July 20 TechRadar Pro industry perspective draws this distinction directly: agents need controlled access to resources, not unnecessary exposure to the secrets that enable that access.
A complementary portfolio perspective is available in the ServingIQ AI decision-log guide.
Prefer managed connections, short-lived authorization, or brokered access that can be limited and revoked. Never paste production credentials into instructions, knowledge documents, or prompts. Treat logs and screenshots carefully as well; they can expose tokens or private values even when the main workflow does not.
The practical test is simple: can the team revoke the assistant's access without changing a human employee's credentials or hunting through prompts for copied secrets?
6. Put approval gates before consequential actions
Define the actions that require a person to review and approve the exact proposed change. Examples include sending an external message, changing a schedule, updating a financial or resident-related record, publishing content, granting access, deleting data, or making a policy exception.
The approval should show enough context for a meaningful decision: the proposed action, the source information used, the affected system or person, and any uncertainty or missing data. A generic “approve” button without the underlying change is not a real control.
Use the following resource when assigning escalation and recovery ownership: ServingIntel support resources.
As the consequence rises, oversight should rise with it. That is consistent with PwC's July guidance and with the approval model described in OpenAI's July product announcement.
7. Log sources, decisions, actions, and outcomes
An activity count is not an audit trail. For important workflows, the record should answer four questions:
- What source information did the assistant use?
- What decision or recommendation did it produce?
- What action was proposed, approved, or completed?
- What happened after the action?
IBM's July release highlights traces, access visibility, policy enforcement, and credential monitoring as operational controls for running agents. The broader lesson applies across tools: logs should help an operator investigate a failure, not merely prove that the assistant was busy.
For additional independent reference material, review NIST AI Resource Center.
Set a retention period that fits the sensitivity and consequence of the workflow. Restrict log access because the audit record may contain the same sensitive context the assistant used.
8. Define failure stops and a manual fallback
An assistant should stop safely when a required source is missing, two sources conflict, a connection fails, an approval times out, an action returns an unexpected result, or the request falls outside its stated purpose.
Write the fallback as an operating step, not a vague promise to “get a human.” Specify the queue, role, contact path, and information the assistant must pass along. The human should receive the original request, the sources already checked, the reason for the stop, and any proposed next step.
Test the stop conditions deliberately. A workflow is not ready merely because its happy path works.
For another practical workflow in the portfolio, read the SI Receipt control checklist.
9. Review access on a schedule and after every material change
Access tends to grow. New integrations are connected, responsibilities change, and a narrow pilot becomes part of a larger workflow. Set a recurring review for the owner to confirm that the purpose is still valid, permissions remain minimal, approval gates still match the risk, logs are useful, and old connections have been removed.
Also trigger a review when the assistant's model, tools, connected data, autonomy, owner, or business process changes. A permission set approved for a drafting assistant should not automatically carry over when the assistant begins sending or updating records.
Record the decision: keep, reduce, expand, pause, or retire the access. Silence should not count as renewal.
A minimum viable access brief
Before launch, one page should be enough to show the control design. Include:
For additional restaurant and senior-living technology context, consult ServingIntel News & Insights.
- purpose and stop list;
- owner and escalation contact;
- machine identity;
- connected systems and data fields;
- read and write capabilities;
- secrets and authorization method;
- required human approvals;
- log location and retention period;
- failure stops and manual fallback; and
- next access-review date.
For restaurant and senior living operators, connect this brief to the real service workflow rather than treating it as isolated technical paperwork. The right boundary depends on where staff, guests, residents, payments, schedules, and support responsibilities intersect. ServingIntel's overview of support operations provides useful context for escalation and service ownership, while its senior living dining workflow material illustrates why operational context matters when systems support resident-facing work.
Start narrow, then earn broader access
An assistant becomes more useful when it can work with the systems where operations happen. That usefulness also increases the consequence of a wrong action, an overbroad permission, or an unclear handoff.
The safest sequence is progressive: observe, draft, propose, approve, act, and then review. Each step should be earned with evidence from the previous one. A narrow assistant with a clear owner, visible permissions, meaningful approvals, usable logs, and a tested fallback is more valuable than a broadly connected assistant that no one can confidently explain.
Access is not a one-time setup task. It is an operating decision that should remain visible for as long as the assistant can act.
For a final neutral reference point, consult CISA artificial-intelligence guidance.
Sources
- OpenAI, July 9, 2026
- IBM, July 2, 2026
- PwC, July 17, 2026
- TechRadar Pro, July 20, 2026