AI Permissions, Logs and Approval Gates: A Business Guide

What do permissions, logs and gates each answer?

Three controls do most of the work in an AI system that touches real records, and they are routinely confused with one another. Permissions decide what is possible at all. Gates decide what needs a person before it happens. Logs record what did happen, in enough detail to answer a question three weeks later. Drop one and the other two weaken. Gates without permissions can be walked around, permissions without logs cannot be checked, and logs without gates simply document the damage in good order.

None of the three needs special software to begin. A permission model can be a page per system. A gate can be an approval step in a tool your team already opens every day. A log can start as structured rows the workflow writes as it runs. What matters is that each answers a specific question on a specific day, usually a day when something has gone wrong and someone senior is asking.

What goes into a written permission model?

A permission model has two halves that are easy to conflate. The first is about people: who may use this system, in which team, for which kind of work. The second is about the system itself: what it may read, what it may change and how far it may go without asking. Write both down for each system. Six lines usually cover it.

1. Who may use it, and who may not.
2. Whose permissions apply when it fetches information.
3. The sources it can read, named precisely rather than by category.
4. The actions it can take, with anything unlisted refused by default.
5. The limits on those actions: amounts, volumes, working hours, retries.
6. Who approves what, and who takes over when that person is away.

The second line is the one teams skip. For question answering, the safer pattern is for the system to use the permissions of the person asking, so an answer cannot travel past existing access. Scheduled workflows have no person to inherit from and need their own scoped account, which is where introducing AI without uncontrolled access starts.

What should a useful log actually record?

A line saying the workflow completed is storage, not evidence. A useful entry lets somebody who was not there reconstruct the decision without running it again. That means the inputs, the sources consulted, the action proposed, the human decision and the result, including the results that were failures.

NIST’s Guide to Computer Security Log Management makes a point worth borrowing wholesale: logging is a process to be planned, with defined roles, written logging policies and a routine for analysing what is collected. It also separates ordinary retention from preservation, which is keeping records you would normally discard because they belong to an investigation. Both ideas transfer directly to an AI workflow.

How long should logs be kept, and who reads them?

Two different questions hide inside that one. How long do you keep records, and how often does somebody look at them? The first is partly a legal matter. In India, CERT-In’s directions of 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000, require service providers, intermediaries, data centres, body corporate and government organisations to enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days within Indian jurisdiction, to be provided to CERT-In when an incident is reported or when directed.

The second question is the one that improves systems. Agree who samples the log, how often, and what they are looking for. Approvals granted in under five seconds, repeated retries, refusals, actions taken at two in the morning and the same customer appearing four times in a week are all worth a second look. Logs about people are themselves sensitive: record what you need, mask what you do not, restrict who can open them and give them a deletion date.

How do you design an approval gate people can actually use?

A gate is a decision, not a checkbox. Four settings decide whether it protects the business or merely adds a day to everything.

• The threshold: what crosses the gate. An amount, a customer type, a first-time record, a case the system flagged as uncertain.
• The evidence: the original request, the sources used, the proposed action and an honest note on what could not be established.
• The response: approve, edit or reject, with a reason captured on rejection so the rules can improve.
• The timeout: what happens when nobody answers. Escalate to a named person, or hold and tell someone. Never approve by default.

A request that lands in a shared inbox with nobody’s name on it is not a gate. Designing the human decision into the workflow goes deeper into the reviewer’s experience. The point here is that all four settings are decisions you record, rather than defaults you inherit from whichever tool you happen to use.

What thresholds and timeouts are sensible at the start?

Start tighter than feels necessary. Approve every case for the first few weeks, however tedious, because that period is what produces the evidence for every threshold you set afterwards. Then loosen one thing at a time and watch the correction rate rather than the volume.

Timeouts deserve the same care as thresholds. Decide what happens overnight, over a weekend and during a festival week when the named reviewer is unreachable. The fallback should be another person, a narrower action or a pause, and it should be written down before the first case reaches it.

Which controls suit which kind of action?

Actions are not equally consequential, and treating them as though they were produces either paralysis or exposure. Two questions sort them quickly. How large is the effect if it is wrong, and how easily can it be undone? A wrong internal note is trivial. A wrong message to a customer cannot be recalled, however small the sum involved. A wrong payment is both large and hard to reverse.

The OWASP GenAI Security Project reaches a similar conclusion from the security side, advising that consequential actions require user approval and that authorisation be checked in the system being changed rather than left to the model to respect. Use the table as a starting point and then argue with it, because the right line depends on your customers, your regulator and how quickly your team can put a mistake right.

What is a sensible starting set for one workflow?

1. One page naming the system, its owner, its readable sources and its permitted actions.
2. A service account holding those permissions and nothing else, with a review date.
3. A log entry per run: inputs, proposed action, decision, approver, outcome and cost.
4. One gate on the most consequential action, with a named reviewer and a timeout.
5. A weekly sample of twenty entries, read by the owner, for the first six weeks.
6. A written rule for what would make you close a gate that you had opened.

All of this is cheap to design in and expensive to retrofit. BYBO treats permissions, evaluations, logs and cost visibility as part of the Infrastructure & Governance foundation rather than a later phase. The measures that tell you whether the arrangement is working are a separate discipline, covered in how to measure whether an AI system is working.