Access Controlled Website Interaction for Agentic AI with Delegated Critical Tasks

This is an authors’ copy of the paper to appear in Companion Proceedings of the ACM Web Conference 2026 (W Companion ’26). Access Controlled Website Interaction for Agentic AI with Delegated Critical Tasks Sunyoung Kim Arizona State University Tempe, AZ, USA skim638@asu.edu Hokeun Kim Arizona State University Tempe, AZ, USA hokeun@asu.edu Abstract Recent studies reveal gaps in delegating critical tasks to agentic AI that accesses websites on the user’s behalf, primarily due to limited access control mechanisms on websites designed for agentic AI. In response, we propose a design of website-based interaction for AI agents with fine-grained access control for delegated critical tasks. Our approach encompasses a website design and implementation, as well as modifications to the access grant protocols in an open-source authorization service to tailor it to agentic AI, with delegated critical tasks on the website. The evaluation of our approach demonstrates the capabilities of our access-controlled website used by AI agents. CCS Concepts • Security and privacy→Access control;• Information sys- tems→Web applications;• Computing methodologies→ Natural language generation. Keywords Access control, Delegation, Website design, Agentic AI ACM Reference Format: Sunyoung Kim and Hokeun Kim. 2026. Access Controlled Website Inter- action for Agentic AI with Delegated Critical Tasks. In Proceedings of the ACM Web Conference 2026 (W ’26), April 13–17, 2026, Dubai, United Arab Emirates. ACM, New York, NY, USA, 4 pages. https://doi.org/10.1145/ 3774904.3792864 1 Introduction Recent advances in agentic artificial intelligence (agentic AI) have enabled autonomous systems to perform complex, critical tasks such as business operations and e-commerce [16], algorithmic trad- ing [18], or healthcare [12]. The release of OpenAI’s Agent Kit [14] has brought agentic AI to everyday life, making it more accessible for both developers and regular users. These AI agents act on behalf of users, accessing web services and performing critical tasks. However, the absence of robust access control of agentic AI presents severe risks, such as unauthorized purchases, identity theft, and data exposure [5]. Thus, research on agentic AI has in- creasingly focused on access control. A recent study [3] proposes zero-trust models to manage agent identities in multi-agent sys- tems, and extend authentication protocols such as OpenID Connect to enable verified delegation [17]. Major financial providers have also begun exploring this area. For example, Mastercard’s Agent This work is licensed under a Creative Commons Attribution 4.0 International License. W ’26, Dubai, United Arab Emirates © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2307-0/2026/04 https://doi.org/10.1145/3774904.3792864 Pay [11] enables AI agents to make real-world payments on behalf of users using tokenization [10] capabilities. However, this system operates exclusively within the Mastercard payment ecosystem and does not provide a generalized framework. In addition, our recent case study [9] reveals that current e- commerce websites lack a standardized model to delegate transac- tional authority to agentic AI. Specifically, most existing e-commerce platforms do not meet the operational needs of agentic AI, such as setting user-defined constraints, performing automated purchases, and handling logins without human intervention. This clearly demonstrates the need for agent-aware website design principles. To address these gaps, this paper proposes an open-source soft- ware approach toward fine-grained access-controlled (authorized) website interaction for agentic AI carrying out critical tasks securely delegated by human users. Our technical contributions include: •Extension of an open-source authorization toolkit for distributed systems to enable secure access delegation to AI agents, by secure delivery of cryptographic tokens for access-controlled interaction between AI agents and websites. • Design of website interface for human users to specify fine- grained access control for access delegation, as well as for AI agents to perform critical tasks delegated by human users. •Open-source release of full design of our proposed extension and website, followed by evaluation and validation of our design, with in-depth discussions for future directions. All implementa- tion artifacts of this paper are publicly available on GitHub 1 . 2 Proposed Approach Figure 1 shows an overview of our approach to enable secure access delegation among (a) human users, (b) AI agents and (c) a website using (d) Auth [8], a key entity of an open-source toolkit for decen- tralized authorization services, Secure Swarm Toolkit (SST) [6]. An Auth acts as a key distribution center (KDC) [7,13] for issuing cryp- tographic session keys for secure, authorized (access-controlled) communication with specified validity periods. 2.1 Secure Access Delegation An Auth [8] uses local database tables to store credentials and the necessary information to authenticate and authorize network entities. Since the existing design of Auth and SST [6] does not support access delegation, in this paper, we extend Auth’s database schema and data types to enable secure access delegation. Figure 2 describes the Auth’s key database tables and our exten- sion (highlighted in red boxes) using user and AI agent examples. 1 https://github.com/asu-kim/agentic-website, these artifacts include source code for the frontend and backend of our website, agent-side scripts, and experimental logs. arXiv:2603.18197v1 [cs.AI] 18 Mar 2026 W ’26, April 13–17, 2026, Dubai, United Arab EmiratesSunyoung Kim and Hokeun Kim (d) Auth (④A, ⑦A) check ExpectedOwner Groups (a) Human User (b) AI Agent (c) Website ② get SessionKeyId ③ give SessionKeyId ⑦ request SessionKey with SessionKeyId ⑧ give SessionKey ④ request SessionKey with SessionKeyId ⑤ give SessionKey ⑥ access request with SessionKeyId ⑨ give access ① delegate access Figure 1: Our proposed system’s workflow for secure access delegation of our approach, where the user grants delegated access to the agent for accessing the website. (c) Cached Session Key Table Session Key ID Expected Owner Groups OwnersPurpose Max Num Owners Expiration Time Relative Validity Crypto Spec Key Value 0000 HighTrust- Agents, Websites myWebsite, alice- BusinessAgent Delegation: HighTrustAgents, Websites 2 11/4/2025, 16:00 2 hours AES128 CBC: SHA256 b6 0e ac 58 ... 0001 Medium- TrustAgents, Websites alice- PersonalAgent Delegation: MediumTrust- Agents, Websites 2 11/4/2025, 17:00 1 hours AES128 CBC: SHA256 3c 2d ac 67 ... 0002 LowTrust- Agents, Websites NULL Delegation: LowTrustAgents, Websites 2 11/5/2025, 16:00 5 min AES128 CBC: SHA256 f8 ad A2 77 ... ........................... NameGroup DistributionKey ExpirationTime Distribution KeyValue ... userAliceUsers01/10/2027 10:4050 20 c3 9b ...... myWebsiteWebsites01/10/2027 10:4235 3b 2f 49 ...... aliceBusinessAgentHighTrustAgents11/14/2025, 16:00b0 53 4e 7b ... ... alicePersonalAgentMediumTrustAgents11/14/2025, 17:008a 32 11 c4 ...... aliceCasualAgentLowTrustAgents11/15/2025, 16:009e 4a 55 0f ...... ............... (a) Registered Entity Table Requesting Group Target Type Target MaxNum Session KeyOwners Session CryptoSpec Validity (Absolute / Relative) UsersDelegation HighTrustAgents, Websites 2 AES-128-CBC: SHA256 1 day / 2 hours UsersDelegation MediumTrustAgents, Websites 2 AES-128-CBC: SHA256 12 hours / 1 hours UsersDelegation LowTrustAgents, Websites 2 AES-128-CBC: SHA256 6 hours / 5 min. .................. (b) Communication Policy Table Figure 2: Extended Auth database tables supporting secure access delegation with example data rows. • Registered entity table (Figure 2a) stores credentials and unique string identifiers for each network entity, the group the entity belongs to, as well as cryptography and validity periods of distribution keys, which are used for secure delivery of cached session keys to be used for access control of entities. ◦Our example shown in Figure 2a includes a user named Alice (userAlice), a website (myWebsite), and Alice’s three AI agents (Business,Personal,Casual), belonging to groups, Users, Websites, and High/Medium/LowTrustAgents. •Communication policy table (Figure 2b) governs the access between entities, for example, which entity can gain access to which entity (or which group of entities), as well as the type of the communication target, crypto, and access duration (relative validity starting from the first access and absolute validity as a hard deadline for the last access attempt). Auth always consults with this table before granting access in the form of session keys. ◦Our extension in this paper introduces a new target type, Delegation, to specify that the requesting group that initi- ates access delegation, while not being part of the commu- nication. In Figure 2b, for example, the requesting group is Users, which Alice belongs to. Also, our new target type describes two entity groups using delegated access, with the first group (e.g., agents withHigh/Medium/Lowtrust) granted delegated access byUsersto access the second group (e.g., Websites). For example, Alice can request Auth for delegated access for one of her agents to a target website. •Cached session key table (Figure 2c) stores cryptographic keys as tokens for granted accesses among network entities. This table stores each session key’s information, including the current owners, unique ID, designated purpose, and expiration time. This table refers to a session key as “cached” because Auth temporarily stores these keys for granted accesses so that Auth can provide the session key for other requesting entities. ◦ Our extension adds a new column,ExpectedOwnerGroups, as shown in Figure 2c, which is populated when a session key for delegated access is created, referring to theTarget column of the communication policy table. Auth ensures that each owner is from each group as specified in the expected owner groups for secure access delegation. We walk through the access delegation process of our proposed system in Figure 1 using the example database tables in Figure 2. A user initiates delegation (Figure 1 1 ○) by requesting Auth to cre- ate a session key for an agent, providing the agent’s trust level. Auth checks the communication policy table for the appropriate validity period for the given trust level and generates a new session key to be stored in the cached session key table with an initially empty Owner and returns the session key’s ID to the user (Figure 1 2 ○). Upon receiving the session key ID from the user (Figure 1 3 ○), the agent requests the corresponding session key from Auth (Fig- ure 1 4 ○), Auth checks whether the requesting agent belongs to one of the session key’sExpectedOwnerGroups(Figure 1 4 ○A). If the agent is authorized but not yet an owner, Auth returns the session key and registers the agent as the owner (Figure 1 5 ○). If the agent is not in theExpectedOwnerGroups, Auth denies the request. Sim- ilarly, if an already-registered agent attempts to re-request the key, Auth rejects it to prevent duplicate issuance. Through this, Auth ensures that delegated session keys are issued exactly once to each authorized agent and never shared with unauthorized ones. 2.2 Website Design We design the website to provide secure and fine-grained access delegation for autonomous agents acting on behalf of a human user. We implement the frontend in JavaScript using a React 2 framework, and build the backend with Python Flask 3 . Figure 4 shows the workflow of our website. Human users con- figure the access scopes of their agents, and each agent interacts with the website through a verifiable authentication workflow co- ordinated with the Auth entity. The website’s role is to enforce 2 https://react.dev/ 3 https://flask.palletsprojects.com/en/stable/ Access Controlled Website Interaction for Agentic AI with Delegated Critical TasksWWW ’26, April 13–17, 2026, Dubai, United Arab Emirates Human User AI Agent React Auth Database Website FrontendBackend Python Flask Node.js Figure 3: Overview of our website design. Human User Login AI Agent Login Register Signed Up? Sign In No Yes Human User Dashboard Open Agent Access Control Set Access Scope Save Policy Login with Session Key ID HMAC Match Denied Login No AI Agent Dashboard Request User’s Data Policy Check Yes Session Expires Yes No Pass Fail Open Website Open Website (a) Human User Workflow(b) AI Agent Workflow Return Code 403 Return Data with Code 200 Trust Level Check Perform Critical Task Figure 4: Website workflows from the perspective of (a) hu- man users and (b) AI agents. these user-defined policies, ensuring that only authorized agents can operate within their assigned boundaries. When an agent attempts to log in, the website generates and displays a 32-digit random nonce. The agent then computes a keyed- hash message authentication code (HMAC) [2] using the website- generated nonce and the session key obtained at (Figure 1 5 ○), and submits both the session key ID and the resulting HMAC value as its proof of authentication (Figure 1 6 ○). Upon receiving these values, the website contacts Auth to obtain the corresponding session key (Figure 1 7 ○). Auth verifies the ses- sion key ID and the requesting entities authorization (Figure 1 7 ○A) and returns both the session key and the agent’s group information, which was registered as the key’s owner during the delegation process in Section 2.1. After receiving the session key (Figure 1 8 ○ ), the website calculates the HMAC value over the same nonce. Au- thentication succeeds only if the HMAC values generated by the agent and the website match, confirming that the agent genuinely possesses the valid session key issued by Auth (Figure 1 9 ○). After successful authentication, the website uses the agent’s group name and the relative validity period provided by Auth to determine which data the agent can access and to configure the session lifetime. The relative validity period specifies how long the agent may operate before re-authentication is required. When the agent issues a data request, the website evaluates the request against the user-configured access-control policy. If the agent attempts to access information outside its authorized scope, the website rejects the request and returns an error. Table 1: Summary of aspects validated by our evaluation. Evaluation Aspect Test Scenario Expected Behavior Observed Results Authentication Agent computes HMAC with correct session key Login succeeds only with valid key 100% success with correct key; 0% with invalid key Fine-Grained Access Control Low-trust agent requests email and phone fields Allowed: email; Denied: phone email returned 200; phone blocked 403 Unauthorized Access Handling Invalid agent requests session key or repeats request Auth rejects unauthorized or repeated request Unauthorized: 100% refused; Repeated request: 100% rejected Session Management Session used after relative validity period Session should be terminated automatically 100% Auto terminated With the retrieved user’s data, the agent can perform a mock critical task on the website. For demonstration purposes, we include a simulated purchase workflow on the website as the critical oper- ation that the agent can execute. In the critical task interface, the agent enters the item name provided by the user and uses the user’s address, card information, and phone number retrieved from the website. The agent can then perform the mock purchase, showing how a highly trusted agent handles sensitive delegated operations. By combining user-defined policy enforcement, HMAC verifi- cation with the session key, and trust-based session management, the website ensures that autonomous agents operate strictly within their delegated authority. 3 Evaluation As shown in Table 1, to evaluate our approach, we focus on vali- dating four key aspects of the system: authentication correctness, fine-grained access control, handling unauthorized access, and ses- sion management. The experiments are implemented in Python 3 using OpenAI’s gpt-oss-20b model [15] for agent-side reasoning and decision-making. As shown in Figure 4 (a), the system, includ- ing the agent, website, and SST’s Auth, is deployed on the ASU Sol Supercomputer [1] equipped with an NVIDIA A100 GPU, while the website interface is accessed through the Firefox browser. Authentication via Login Process. We verify that authenti- cation succeeds only when the agent has the correct session key value. Using the session key retrieved from Auth, the agent com- putes the HMAC over the website-generated nonce. Login succeeds consistently when the session key is valid. Fine Grained Access Control. We test fine-grained access con- trol using agents with different trust levels. Agents with permissions limited to specific fields (e.g., email) successfully retrieve only the allowed data, while all attempts to access higher-privilege fields (e.g., phone or address) are rejected. These results confirm that user-configured, per-agent scopes are enforced correctly. Unauthorized Access Handling. We evaluate how the system handles incorrect or unauthorized requests issued toward Auth. If an agent requests a session key twice using the same session key Id, Auth correctly recognizes the repeated request and denies it. More importantly, when an agent outside theExpectedOwnerGroups attempts to obtain a session key, Auth consistently rejects the re- quest. This ensures that agents cannot impersonate one another or escalate privileges through unauthorized key requests. W ’26, April 13–17, 2026, Dubai, United Arab EmiratesSunyoung Kim and Hokeun Kim Case Average (ms) Std. (ms) High-trust agent (success) 127,248.811,330.0 Medium-trust agent (success) 140,060.217,407.0 Low-trust agent (success) 137,842.46,733.4 Unauthorized 98,690.711,780.6 (a) Latencies with average and standard deviation (std.). Avg Latency (s) 0 50 100 150 HighMediumLowUnauth- orized (b) Latency comparison chart. Figure 5: Comparison of delegated-access latency across trust levels and unauthorized requests. Session Management. To validate temporal security policies, we set the session expiration time using the relative validity period embedded in the session key. After the duration expires, the web- site automatically invalidates the session and logs out the agent. This behavior confirms that time-based trust enforcement works predictably and prevents sessions from being reused. Summary. We measure the success rate of the four evaluation aspects across five trials for each condition and agent trust level. All valid agents consistently achieve a 100% success rate in au- thentication, authorized access, and correct session termination after expiration. In contrast, invalid operations such as using in- correct session keys, attempting to obtain session keys outside the ExpectedOwnerGroups, or issuing repeated session key requests consistently fail with a 0% success rate. Latency Measurement. Additionally, we measure the end-to- end latency of the delegated access workflow, defined as the time from the beginning of the agent’s execution to the moment the agent successfully retrieves the permitted data from the website. As summarized in Figure 5, the end-to-end average latency of unauthorized key requests (98.7 seconds) is significantly lower than the end-to-end average latency of successful delegated ac- cess (127–140 seconds). This is because Auth rejects session key requests from entities not in theExpectedOwnerGroups, and the agent cannot proceed with any website interaction. The medium- and low-trust agents show slightly higher latency due to variability in the agent-side LLM inference time, not due to the trust levels. Since our system is deployed on the local host on the ASU Sol su- percomputer [1], the measured end-to-end latency does not include network latency. In a distributed deployment, the total end-to-end latency would additionally depend on round-trip communication between the agent, Auth, and the website. Assuming symmetrical network latencies, the total latency can be represented as, 퐿 푡표푡푎푙 = 퐿 푒2푒 +4× 퐿 푎2퐴 +4× 퐿 푤2퐴 + 푥 × 퐿 푎2푤 (1) where퐿 푒2푒 is the end-to-end latency measured in Figure 5,퐿 푎2퐴 and퐿 푤2퐴 are latencies between the agent/website and Auth, respec- tively, and퐿 푎2푤 is the agent-website latency with푥for the number of agent-website interactions. This푥is expressed as푥=2+ 푛, where2 is for one request to load the login page and another re- quest to submit the HMAC value for authorization, whereas푛is for푛additional requests corresponding to retrieving the number of sensitive data items. 4 Discussion By leveraging SST [6], an open-source and fully decentralized key distribution center (KDC), our design avoids reliance on third-party cloud infrastructure, allowing the proposed system to operate en- tirely locally and independently. This design enables fine-grained, per-agent permissions, managed by individual entities, such as households, companies, schools, or hospitals. Our approach can be generalized beyond AI agents and support any delegated-authority configuration involving human-to-entity or entity-to-entity dele- gation, tailored to an autonomous delegation for various scenarios. Although the proposed approach has been implemented and functionally tested, formal verification remains future work. Proper- ties such as correct ownership enforcement, enforcement of access scope boundaries, and consistency between website-side and Auth- side session-key checks can be modeled and validated using formal verification tools, such as Alloy 4 [4], to guarantee no authorization violations occur under any execution or communication path. Acknowledgments This work was supported in part by the NSF grant POSE-#2449200. References [1]Arizona State University Core Research Facilities. Accessed on 2025-11-14. Com- puting and Data Service. https://cores.research.asu.edu/research-computing/ [2] FIPS PUB 198-1. 2008. Federal information processing standards publication: The keyed-hash message authentication code (HMAC). Information Technology Labratory, National Institute of Standards and Technology (NIST), Gaithersburg, MD 20899–8900 (2008). [3]Ken Huang et al.2025. A novel zero-trust identity framework for agentic AI: Decentralized authentication and fine-grained access control. arXiv preprint arXiv:2505.19301 (2025). [4]Daniel Jackson. 2012. Software Abstractions: logic, language, and analysis. MIT press. [5]Raihan Khan, Sayak Sarkar, Sainik Kumar Mahata, and Edwin Jose. 2024. Security threats in agentic AI system. arXiv preprint arXiv:2410.14728 (2024). [6]Hokeun Kim, Eunsuk Kang, Edward A Lee, and David Broman. 2017. A toolkit for construction of authorization service infrastructure for the Internet of Things. In Proceedings of the Second International Conference on Internet-of-Things Design and Implementation. 147–158. [7]Hokeun Kim and Edward A Lee. 2017. Authentication and Authorization for the Internet of Things. IT Professional 19, 5 (2017), 27–33. [8] Hokeun Kim, Armin Wasicek, Benjamin Mehne, and Edward A Lee. 2016. A secure network architecture for the internet of things based on local authorization entities. In 2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud). IEEE, 114–122. [9] Sunyoung Kim and Hokeun Kim. 2025. A Case Study on Delegating Critical Tasks to Agentic AI and Prototype Access Control Methods. In the IEEE 5th Cyber Awareness and Research Symposium 2025 (CARS’25). [10]Mastercard. 2024. Tokenization explained: Protecting sensitive data and strength- ening every transaction. https://w.mastercard.com/us/en/news-and-trends/ stories/2025/what-is-tokenization.html Accessed: 2025-08-20. [11]Mastercard. 2025.Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI.https: //w.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard- unveils-agent-pay-pioneering-agentic-payments-technology-to-power- commerce-in-the-age-of-ai.html Accessed: 2025-08-20. [12]Michael Moritz, Eric Topol, and Pranav Rajpurkar. 2025. Coordinated AI agents for advancing healthcare. Nature Biomedical Engineering (2025), 1–7. [13]B Clifford Neuman and Theodore Ts’o. 1994. Kerberos: An authentication service for computer networks. IEEE Communications magazine 32, 9 (1994), 33–38. [14]OpenAI. 2025. Introducing AgentKit. https://openai.com/index/introducing- agentkit/ Accessed: 2025-10-10. [15]OpenAI. 2025. Introducing gpt-oss. https://openai.com/index/introducing-gpt- oss/ Accessed: 2025-11-14. [16]PYMNTS. 2024.AI To Power Personalized Shopping Experiences In 2025.https://w.pymnts.com/artificial-intelligence-2/2024/ai-to-power- personalized-shopping-experiences-in-2025/ Accessed: 2025-08-14. [17]Tobin South et al.2025. Authenticated delegation and authorized AI agents. arXiv preprint arXiv:2501.09674 (2025). [18]Wentao Zhang et al.2024. A multimodal foundation agent for financial trading: Tool-augmented, diversified, and generalist. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 4314–4325. 4 https://alloytools.org/