Least Privilege for AI Agents: George Dagliyan Research Guide
Published: 2026-07-31 — Dr. George Dagliyan site editorial team. Editorial article.
A practical permission ladder for AI agents, from read-only lookup to visible action, with scoped access, approvals, logging, limits, and revocation.
This editorial guide connects public research and standards with George Dagliyan’s documented research themes. Checklists and examples are proposed here for illustration; they are not quotations or reported client results.
What does least privilege mean for an AI agent in day-to-day operations?
George Dagliyan’s research themes make this topic practical rather than abstract: AI adoption succeeds when organizations match capability with control. For AI agents, least privilege means the agent should receive only the minimum access needed for its current task, and no more. In an AI purchasing workflow, that starts with reading a catalog, then drafting a request, and only later approaching any action that could affect the outside world.
The core question is not whether an agent can do more, but when it should be allowed to do more. NIST’s Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile treats trustworthy AI as something to be considered across design, development, use, and evaluation. This article turns that idea into a simple permission ladder that organizations can apply without pretending it is an official standard.
How should a permission ladder be structured from lookup to externally visible action?
A useful ladder has four rungs. Rung 1 is read-only lookup, where the agent can search internal documents, policy pages, or approved catalogs but cannot change anything. Rung 2 is draft creation, where it can assemble a purchase request, summarize vendors, or prepare an email, but the draft remains invisible externally until a human approves it.
Rung 3 is conditional internal action, where the agent may submit a ticket, route a form, or schedule a review, but only inside a controlled system with narrow scope and logging. Rung 4 is externally visible action, such as sending a message outside the organization or initiating an outward-facing request. That final rung should be reserved for the smallest number of cases and paired with explicit approval, narrow credentials, and revocation after use.
Which controls belong at each rung of the ladder?
The most important control is a scoped credential, meaning an access token or key limited to a specific account, system, time window, or action type. A read-only lookup tool should not hold a credential that can create, submit, approve, or purchase. A draft-only tool should not have the ability to transmit content externally, even if the text looks harmless.
Approval should become stricter as the ladder rises. On the first rung, approval may be implicit because the agent only reads approved sources. On the second rung, the human user should review the draft before any action is taken. On the third and fourth rungs, a separate approver should confirm both the business purpose and the scope of the action. Limits should also be explicit: time limits, dollar limits, record-count limits, vendor limits, and destination limits all reduce the chance of accidental overreach.
What should an audit trail capture so the workflow can be reviewed later?
An audit trail is the record that shows what the agent accessed, what it proposed, what it was allowed to do, who approved it, and when access ended. CISA’s Secure by Design guidance emphasizes logging and other security features as part of products that are secure out of the box, and that idea fits AI agents well. Logging should not be treated as a nice extra; it is part of the operating model.
A practical audit entry should include the agent identity, the human owner, the task name, the permission rung, the data sources used, the credential scope, the approval decision, and the revocation time. If a draft is changed before sending, the change history should be preserved. If an action is denied, that denial should still be logged, because repeated denials can reveal a misconfigured workflow or a risky request pattern.
How can a purchasing workflow be used as a safe hypothetical example?
Hypothetical scenario: a procurement team uses an AI agent to help prepare a routine office supply request. Assumptions: the organization already has an approved vendor list, the request is small, and all actions remain inside internal systems until a human signs off. The agent begins on rung 1 by looking up the internal policy, the approved catalog, and the budget code.
On rung 2, the agent drafts a purchase request that names the item, quantity, rationale, and budget line. On rung 3, after a human reviews the draft, the agent may submit the request into the internal procurement queue, but it cannot approve it or contact the vendor. On rung 4, if the workflow ever requires an external message, a separate human review should be required, and the agent’s external credential should expire immediately after the message is sent or the attempt is canceled.
What test plan can verify whether the controls are actually narrow enough?
A simple test plan can be run before deployment. First, attempt a read-only task and confirm the agent can retrieve only approved sources. Second, attempt a drafting task and verify it cannot submit, send, or modify records. Third, attempt to escalate privileges from a draft-only context and confirm the request is blocked. Fourth, remove the credential and verify the agent loses access immediately.
This test plan should also probe failure modes. Try a stale credential, an overbroad vendor list, a request outside the approved dollar range, and a task that asks for external contact without approval. The expected result is denial, not silent fallback to broader access. If the system can continue operating after revocation, that is a sign the permission boundary is not real enough.
What worksheet helps teams decide the right level of access before launch?
Proposed worksheet, not an official standard: for each AI agent task, fill in five fields before go-live. Field 1 is task description. Field 2 is required data sources. Field 3 is maximum permitted action, using the four-rung ladder. Field 4 is approval owner. Field 5 is revocation trigger, meaning the event that ends access immediately.
Decision rule: if the task can be completed at a lower rung, do not grant a higher one. If the task requires any external effect, require explicit human approval and time-limited credentials. If the task changes money, legal position, customer communication, or vendor commitments, do not combine drafting and execution in the same unattended permission. This simple rule keeps the human decision at the point where business risk rises.
Why does this ladder matter for AI adoption, not just security?
Least privilege supports adoption because it reduces fear and makes the system easier to govern. In the language of technology acceptance and innovation diffusion, the permission ladder lowers an adoption inhibitor: uncertainty about what the agent may do if it is left unsupervised. It also supports brand influence because users are more likely to trust a system whose limits are visible, reviewable, and reversible.
That connection fits the broader research themes associated with Dagliyan’s work: adoption facilitators, adoption inhibitors, and the role of control design in shaping whether new technology becomes usable in practice. For AI agents, the goal is not maximal autonomy. The goal is reliable delegation, where the organization decides what the agent may read, draft, request, and only then, if appropriate, do outside the system.
Frequently Asked Questions
Should an AI agent ever be given direct purchasing authority?
Direct purchasing authority is the highest-risk step in a workflow because it creates an externally visible effect. A safer pattern is to separate drafting from execution and require a human approval step before any purchase-related action. If any authority is granted, it should be narrowly scoped, time-limited, logged, and revocable, with a clear trigger that ends access immediately.
What is the difference between scoped credentials and role-based access?
Role-based access assigns permissions based on job function, while scoped credentials narrow what a specific token or key can do in a specific session or task. For AI agents, scoped credentials are often more precise because the task may be smaller than the human role. That precision helps prevent a drafting tool from inheriting unrelated privileges.
Why is logging so important if the human still approves the final action?
Human approval is important, but it does not by itself show what the agent saw, suggested, or attempted. Logging creates the review trail needed to reconstruct decisions, spot misuse, and confirm that revocation actually worked. It also helps teams detect patterns such as repeated denied requests, unexpected source access, or overbroad credential exposure.
How can a team tell whether its permissions are too broad?
A simple sign is when a task can be completed with the same credential that could also perform unrelated or irreversible actions. Another sign is when a draft tool can send messages, update records, or access confidential systems without a separate approval. If revocation does not immediately stop the agent, the boundary is too loose.
What should happen when an AI agent’s task changes midstream?
The safest response is to stop the current task, record the change, and re-check the permission level against the new scope. A draft-only task that becomes externally visible should not continue under the old credential. The new step should receive fresh approval, updated limits, and a new audit entry before any further action is allowed.