DEV Community

Cover image for Why Autonomous AI Agents Need Bounded and Revocable Authority
Aridio Silva
Aridio Silva

Posted on

Why Autonomous AI Agents Need Bounded and Revocable Authority

#ai #security #architecture #agents

Why trustworthy Agentic AI needs explicit, enforceable, time-bounded, and revocable permission to act**

Why trustworthy Agentic AI needs explicit, enforceable, time-bounded, and revocable permission to act**

SGAEIA Research Series - Article 2

Aridio Silva

Independent Researcher
Creator of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture

ORCID: 0009-0008-2411-6995

Cover image - Bounded Authority for Autonomous AI Agents. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Contents

This developer-focused edition adapts the public research article for practical design discussions. Its examples are illustrative, not experimental results. It presents public architectural properties and does not disclose private SGAEIA mechanisms or implementation details.

The permission problem changes when software can act

A traditional application often waits for a person to choose the next step. An autonomous AI agent may interpret a goal, call tools, move data between services, and delegate subtasks with less direct human involvement. Once a system can cause changes, security has to consider the agent’s authority to act, not only whether it can access information [1, 2].

Authentication can identify an agent or validate a request. That is necessary, but it does not answer whether this agent should perform a particular operation on a particular resource, for this task, under current conditions, or how long that permission should last. The central design question becomes: What may this agent do, on whose behalf, under which conditions, and how can that authority be withdrawn?

This article develops bounded and revocable authority as a security property for autonomous AI systems and a core principle of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture [3]. The aim is to let agents perform useful work while keeping their permissions explicit, limited, enforceable, observable, and withdrawable.

Capability is not authority

An email integration might technically allow an agent to search, read, send, forward, label, and delete messages. If the task is “Find this week’s invoices and summarize them,” the technical availability of those operations does not mean the agent should be allowed to use all of them. A read-and-summarize task does not implicitly authorize forwarding attachments or deleting messages.

That distinction is simple and important:

Capability describes what an agent can technically do. Authority describes what it is legitimately permitted to do.

For a developer, the practical implication is that a broad tool connection should not become a broad authorization grant. Give the task only the access it needs, and treat read, write, delete, export, approve, execute, and delegate as distinct operations. Agent-security guidance similarly emphasizes dedicated identities, least privilege, action and resource scoping, controlled tool access, and auditability [4].

Figure 1 - Capability Is Not Authority. Technical capability represents what an agent can do; bounded authority defines the subset it is legitimately permitted to perform.
Figure 1 - Capability Is Not Authority. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Make permissions specific to the task

“Agent A has access to System X” leaves important questions unanswered. A safer design discussion identifies the agent, task scope, resource, permitted action, relevant context, duration, and whether delegation is allowed. These are conceptual dimensions for reasoning about authority, not a required implementation schema [3].

For example, an infrastructure agent assigned to remediate one service incident might need temporary write access to that service. That task alone does not justify permanent access to every service or permission to approve unrelated changes. Similarly, preparing a financial transaction does not automatically authorize the agent to approve or execute it. Least privilege for an autonomous system means the least practical authority for the current purpose, including a time limit [4, 5].

Figure 2 - The Anatomy of Bounded Agent Authority. Authority is jointly constrained by identity, scope, resource, action, context, time, and delegation constraints.
Figure 2 - The Anatomy of Bounded Agent Authority. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Delegation must not widen access

Multi-agent workflows can pass a task from a person to one agent, then to another agent, a tool, and an external service. Each handoff creates an accountability question: where did the permission come from, what part of it was delegated, and did the recipient gain more authority than the delegator had? Research on authenticated delegation highlights the importance of accountability and traceable delegation relationships [1].

A useful design rule is that delegated authority should be equal to or narrower than the authority from which it derives. If Agent A may read a customer record, passing a subtask to Agent B should not give B permission to modify that record. If A’s permission expires after ten minutes, B’s derived permission should not last a day. A downstream agent should not gain authority simply because another component passed it a task [1, 3].

Figure 3 - Authority Must Narrow Through Delegation. Each downstream grant remains equal to or narrower than the effective authority from which it derives.
Figure 3 - Authority Must Narrow Through Delegation. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Permissions can also combine into a capability no one intended. An agent with access to internal documents, a transformation tool, and an external messaging service might be able to retrieve sensitive information, transform it, and send it outside the organization. Each integration may look acceptable in isolation; the composed action path can create a different risk [4, 8]. Review what the agent can accomplish across the whole workflow, not only the permission list for each individual tool.

Plan for expiry and revocation

A permission that was appropriate when a task started may become inappropriate if the task is cancelled, the context changes, a credential is suspected of compromise, or the work is complete. Temporary work should not quietly leave behind permanent privilege. Agent security therefore needs a way to expire or withdraw authority during operation, with downstream systems checking whether permission remains valid [4, 6].

Revocation also raises a delegation question. If Agent A’s grant is withdrawn, should agents whose permissions came only from A continue acting? A governed design should be able to trace where delegated authority came from and consider how revocation applies to dependent grants. A separate, independently authorized grant may need different treatment; the key is to make the provenance and decision reviewable [1, 3].

Figure 4 - Authority Lifecycle and Revocation. Authorization can be requested, evaluated, granted, enforced, monitored, re-evaluated, and revoked or allowed to expire.
Figure 4 - Authority Lifecycle and Revocation. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Check the whole action path

A one-time “allow” decision may not be enough for a workflow that can invoke multiple tools or delegate work. A practical lifecycle to consider is: request an action, evaluate whether it is authorized, grant limited permission, enforce the decision, observe relevant execution, re-evaluate if conditions change, and revoke or expire the permission when it is no longer valid. This is a conceptual SGAEIA model, not a product-specific implementation prescription [3].

At the edge, agents may operate with intermittent connectivity or partial local context. Resilience can require an agent to continue within authority already granted, but a network interruption should not automatically become permission to expand that authority. This separates operational autonomy from unbounded authority [3, 9, 10].

Make controls enforceable and reviewable

A prompt such as “do not delete files” can guide an agent’s behavior, but it is not the same as an authorization control enforced by the systems that expose the files or tools. Security boundaries should not depend solely on an agent choosing to obey them. Independent enforcement, appropriately scoped access, and runtime controls help keep a mistaken or manipulated plan from becoming an authorized external action [4, 6].

After an action, a reviewer should be able to determine who acted, on whose behalf, what resource and operation were involved, what authority applied, whether delegation occurred, and what evidence supports the decision. Auditability is part of the architecture: it helps teams investigate outcomes and assess whether the system stayed within its intended boundaries [1, 4]. Evidence has limits; logs or tests alone do not certify a deployment.

A practical design checklist

For each consequential action an AI agent can take, ask:

  • Actor and purpose: Which agent is acting, and for what task?
  • Resource and operation: Which specific resource can it affect, and which actions are allowed?
  • Conditions and duration: When is the permission valid, and when does it expire?
  • Delegation: Can this authority be passed on, and can the next agent receive anything broader?
  • Withdrawal: How can the permission be suspended or revoked if the task ends or risk changes?
  • Evidence: What can an operator or reviewer inspect afterward?
  • Composition: What can the agent accomplish by combining its tools and permissions?

These questions translate a broad “agent has access” statement into decisions engineers can review across identity, scope, resource, action, context, time, and delegation. The exact controls depend on the system and threat model; using a checklist does not by itself establish that a system is secure [3, 5, 7].

Conclusion

The security of autonomous AI cannot be reduced to whether an agent is authenticated. Identity helps answer who is acting; authority must also answer what the agent may do, against which resources, under what conditions, for how long, on whose behalf, and with what right to delegate.

The engineering goal is not to eliminate useful autonomy. It is to make permission to act explicit, bounded, enforceable, traceable, and revocable. As the SGAEIA principle puts it: Autonomous AI. Governed by Design. Trusted by Evidence.

References

  1. South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Chan, A., & Pentland, A. (2025). “Position: AI Agents Need Authenticated Delegation.” Proceedings of the 42nd International Conference on Machine Learning, PMLR 267, 82211–82231. PMLR.
  2. Chhabra, A., Datta, S., Nahin, S. K., & Mohapatra, P. (2026). “Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges.” IEEE Access, 14, 49455–49482. DOI.
  3. Silva, Aridio. (2026). SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture. Zenodo. DOI.
  4. Yser, Y., & Kohlenberg, T. (2026, July 16). “Least privilege for AI agents: Identity, access, and tool binding.” Microsoft Security Blog. Microsoft.
  5. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. DOI.
  6. OWASP GenAI Security Project. (2026, September 1). Agent Control Standard (ACS). OWASP.
  7. Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. DOI.
  8. OWASP GenAI Security Project. (2025, December 9). OWASP Top 10 for Agentic Applications for 2026. OWASP.
  9. Zhou, Z., Chen, X., Li, E., Zeng, L., Luo, K., & Zhang, J. (2019). “Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge Computing.” Proceedings of the IEEE, 107(8), 1738–1762. DOI.
  10. Singh, R., & Gill, S. S. (2023). “Edge AI: A survey.” Internet of Things and Cyber-Physical Systems, 3, 71–92. DOI.

About the Author

Aridio Silva is an independent researcher based in Brazil working on the architecture, security, governance, and trustworthiness of autonomous and distributed artificial intelligence systems. His research focuses on Agentic AI, Multi-Agent Systems, Edge AI, AI Security, Zero Trust, Security-by-Design, AI Governance, Spec-Driven Development, and continuous security assurance. He is the creator and lead researcher of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture, an open research initiative exploring architectural foundations for secure, governed, auditable, and trustworthy autonomous AI systems operating across distributed edge-cloud environments.

Research & Project Resources

Suggested citation

Silva, Aridio. (2026). Why Autonomous AI Agents Need Bounded and Revocable Authority (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22715664.

License

Except where otherwise noted, the text and original conceptual illustrations in this article are licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0). © 2026 Aridio Silva. You may share and adapt this work for any purpose, provided appropriate attribution is given. The SGAEIA software research artifact remains subject to its own Apache License 2.0.

Autonomous AI. Governed by Design. Trusted by Evidence.

Read the complete public article

Read the canonical article and supporting materials on the SGAEIA homepage. The DEV post is a technical adaptation of the same public research work.

Top comments (0)