A Trust Framework System And Method For Secure, Stateful Interaction Between Agentic Systems And Third Party Tools

Description:FIELD OF THE INVENTION the present invention relates to computer-implemented security architectures. more particularly, it pertains to a trust framework system and method for secure, stateful interaction between agentic systems and third-party tools.

BACKGROUND OF THE INVENTION In the recent artificial intelligence landscape, agentic systems powered by large language models are increasingly expected to integrate with third-party executable tools in order to perform tasks such as data analysis, process automation, customer interaction, and domain-specific operations. While such integrations unlock significant capability, they also introduce critical risks relating to trust, provenance, and secure execution. Conventional methods for connecting AI systems with external tools typically rely on application programming interface (API) keys, static whitelists, or manually configured sandboxes. These approaches are fragile: API keys are prone to leakage or misuse, whitelists become unmanageable as the number of tools grows, and manual sandbox rules cannot consistently enforce fine-grained restrictions. More importantly, they do not ensure the authenticity of the tool itself, they fail to protect sensitive user context during multi-turn interactions, and they offer no way for a tool to securely ask clarifying questions from users. While large language models excel at reasoning and dialogue, they lack built-in mechanisms for cryptographic verification, controlled state management, or secure runtime isolation. Similarly, traditional containerization techniques, though useful for isolation, rely on manual setup and provide no standardized protocol for enabling safe, stateful exchanges between tools and users. As a result, existing architectures fall short for agentic AI platforms that must operate in environments demanding verifiable trust, controlled execution, private and persistent session state, the ability to revoke compromised tools, and safe multi-turn collaboration between users, AI systems, and external tools. Therefore, there is a need for a cryptographically rooted trust framework that brings together certificate-based validation, manifest-driven permission control,

3

secure stateful interaction, and standardized interactive protocols thereby ensuring that tool integrations within agentic systems are both trustworthy and scalable. Prior Arts: US11729023B2 discloses an artificial intelligence integration model that enables third-party software to be incorporated into large-scale digital platforms. While this system addresses interoperability between AI systems and external applications, it does not establish a cryptographically rooted trust framework. In particular, it lacks mechanisms for binding tool artifacts to verifiable manifests, enforcing fine-grained runtime capability restrictions, or maintaining encrypted session state across multi-turn interactions. The disclosure focuses primarily on enabling integration but does not provide guarantees of provenance, authenticity, or secure stateful dialogue between tools and users. US20240195701A1 introduces a framework for assessing trustworthiness in artificial intelligence pipelines, with emphasis on policy-driven governance, explainability, and robustness. Although this approach highlights the importance of trust and compliance in AI systems, it does not contemplate the secure ingestion and execution of third-party tools within agentic platforms. The model does not describe certificate-based validation, sandbox instantiation tied to declared scopes, or encrypted multi-turn interaction protocols. Its focus remains on policy regulation and system-level trust assessment rather than cryptographic provenance verification and stateful tool interaction. While the aforementioned prior arts address various aspects such as integration of third-party software and trust governance in AI, none provide a comprehensive framework for cryptographically verifiable provenance, fine-grained sandbox enforcement, encrypted session state, dynamic revocation, and interactive clarification between users and tools. There is no existing architecture that unifies certificate chains, resignable manifests, secure sandbox execution, and an interactive session protocol to enable trustworthy, stateful collaboration between agentic systems and third-party executables. The present invention overcomes these limitations by introducing a cryptographically rooted trust framework that integrates root-to-customer-to-tool certificate chains, manifest-driven

4

capability enforcement, encrypted session state stores, signed revocation mechanisms, and a standardized interactive session protocol. This architecture ensures that only authenticated tools are ingested, that runtime operations are strictly scoped, that user data remains protected, and that tools can securely engage in multi-turn clarifications with users thereby enabling safe, scalable, and transparent tool integration within agentic AI platforms.

DEFINITIONS The expression “system” used hereinafter in this specification refers to an ecosystem comprising, but is not limited to a system with a user, input and output devices, processing unit, plurality of mobile devices, a mobile device-based application, a visualization platform, and output; and is extended to computing systems like mobile, laptops, computers, PCs, etc. The expression “input unit” used hereinafter in this specification refers to, but is not limited to, mobile, laptops, computers, PCs, keyboards, mouse, pen drives or drives. The expression “output unit” used hereinafter in this specification refers to, but is not limited to, an onboard output device, a user interface (UI), a display kit, a local display, a screen, a dashboard, or a visualization platform enabling the user to visualize, observe or analyse any data or scores provided by the system. The expression “processing unit” refers to, but is not limited to, a processor of at least one computing device that optimizes the system. The expression “large language model (LLM)” used hereinafter in this specification refers to a type of machine learning model designed for natural language processing tasks such as language generation. LLMs are language models with many parameters, and are trained with self-supervised learning on a vast amount of text. The expression “agentic system (AS)”, as used hereinafter in this specification, refers to the large language model–orchestrated platform that validates, ingests, and executes third-party tools within a sandbox and mediates interactions with the user through the Framework API.

5

The expression “root trust authority (RTA)”, as used hereinafter in this specification, refers to the entity that holds the root private key, issues customer certificates, and acts as the ultimate trust anchor in the certificate chain. The expression “customer certificate (CC)”, as used hereinafter in this specification, refers to the signed certificate issued by the Root Trust Authority based on a customer’s submitted public key, establishing a cryptographic identity for that customer. The expression “tool manifest (TM)”, as used hereinafter in this specification, refers to the signed metadata structure that contains the cryptographic hash of the tool artifact, required capability scopes, validity information, and associated signatures. The expression “sandbox”, as used hereinafter in this specification, refers to the isolated execution environment instantiated by the agentic system for a trusted tool, wherein runtime capabilities are limited to the declared scopes in the Tool Manifest. The expression “session state store (SSS)”, as used hereinafter in this specification, refers to the encrypted, per-session store that preserves state across multiple conversational turns and is accessible only by the trusted tool using derived keys. The expression “interactive session protocol (ISP)”, as used hereinafter in this specification, refers to the protocol governing secure multi-turn interaction between the Agentic System and a tool, including ToolRequest, ToolClarify, ToolResult, and ToolError messages. The expression “signed revocation list (SRL)”, as used hereinafter in this specification, refers to the signed list published by the root trust authority that enumerates revoked customers, tools, or compromised keys, and is verified by the Agentic System before tool ingestion or session execution. The expression “framework API”, as used hereinafter in this specification, refers to the generic, signed interface provided by the Agentic System that enables a tool to send and receive secure messages, update session state, and exchange results without exposing raw user data. The expression “Artifact A” used hereinafter in this specification refers to the packaged tool payload that a customer submits to the agentic system—e.g., a binary, container image, or zip

6

bundle. It contains the executable code (and any bundled resources) for the tool. It is separate from the Tool Manifest (TM). Artifact A is the canonical, immutable “thing that runs.” The framework’s security guarantees hinge on binding that artifact’s hash to the signed manifest, verifying it at ingestion, and enforcing its declared scopes at runtime.

OBJECTS OF THE INVENTION The primary object of the present invention is to provide a trust framework system and method for secure, stateful interaction between agentic systems and third-party tools. Another object of the invention is to ensure provenance and authenticity of third-party tools through a certificate chain that binds a root trust authority, customer certificates, and signed tool manifests. A further object of the invention is to enforce fine-grained runtime capability restrictions by registering each tool within a sandbox environment that thereby derives the permissions directly from the declared scopes in the tool manifest. Another object of the invention is to preserve the sensitive user context while enabling multi-turn interactions by maintaining an encrypted Session State Store that is accessible only by the trusted tool through derived cryptographic keys. Yet another object of the invention is to provide a standardized interactive session protocol that allows tools to securely exchange messages, request clarifications, return results, or report errors without exposing raw user data. A further object of the invention is to enable dynamic distrust through a signed revocation list, allowing compromised tools, customers, or keys to be invalidated in real time across all agentic systems.

7

A final object of the invention is to ensure scalability and transparency by automating certificate issuance, manifest signing, and sandbox configuration, thereby allowing agentic AI platforms to safely integrate and manage a large number of third-party tools.

SUMMARY: Before the present invention is described, it is to be understood that the present invention is not limited to specific methodologies and materials described, as these may vary as per the person skilled in the art. It is also to be understood that the terminology used in the description is for the purpose of describing the particular embodiments only and is not intended to limit the scope of the present invention. The present invention discloses a trust framework system and method for secure, stateful interaction between agentic systems and third-party tools; wherein the trust framework system comprises a user, a root trust authority (RTA), a customer registration module (CRM), a trusted authority (TA), and an agentic system further includes an agentic system ingestion engine (ASIE),an interactive session protocol, a framework API, an LLM orchestrator, a tool packaging and manifest generation module, a revocation service module, an execution engine, and a sandboxed tool. In an aspect, the user interacts with the agentic system through input devices using chat or voice. The RTA, functioning as a hardware security module, manages the root private key and certifies customer identities. The CRM generates customer key pairs and facilitates secure customer registration with the RTA. The TA validates signatures, re-signs manifests, and establishes a certificate chain. The agentic system provides a secure execution environment where the ASIE validates and registers tools, the LLM orchestrator manages sessions, the framework API enables communication, the tool packaging module creates signed manifests, the revocation service maintains signed revocation lists, and the execution engine runs sandboxed tools under OS-level restrictions.

8

In another aspect, the system operates by receiving a natural-language request from the user, which the LLM orchestrator interprets to identify the appropriate tool; a ToolRequest is created with a session identifier (SID), user input, and encrypted state, then forwarded to the execution engine. The tool undergoes verification by the TA, including certificate chain validation, artifact hash checking, and revocation list consultation. Upon validation, the execution engine launches a sandbox, loads the verified artifact, and executes the tool with the provided input and session state. The tool processes the request, generates a result, and returns a signed ToolResponse to the LLM orchestrator, which merges the output into the conversation and delivers the final answer to the user. If clarification is required, the tool issues a ToolClarify message, prompting a user response that is looped back into execution until a ToolResult is achieved. In yet a further aspect, the invention provides multiple benefits, including cryptographic provenance through certificate chains, ensuring only trusted tools with valid manifests are executed. It guarantees that only the intended tool can decrypt its own session state while maintaining stateful, multi-turn interactions. Fine-grained capability enforcement is achieved via sandbox-controlled scopes, reducing reliance on manual IAM policies. The signed revocation list enables rapid dynamic distrust of compromised keys or malicious tools without system downtime. The framework also supports scalable onboarding, as customers can register and package tools independently with automated signing. Additionally, the design is LLM-agnostic, allowing any agentic system, regardless of its underlying model, to adopt the trust framework for secure and verifiable tool execution.

BRIEF DESCRIPTION OF DRAWINGS: A complete understanding of the present invention may be made by reference to the following detailed description which is to be taken in conjugation with the accompanying drawing. The accompanying drawing, which is incorporated into and constitutes a part of the specification, illustrates one or more embodiments of the present invention and, together with the detailed description, it serves to explain the principles and implementations of the invention. FIG.1. illustrates the schematic of the system.

9

FIG. 2 illustrates the Logical block diagram of the overall trust framework, showing the root trust authority, customer, trusted authority, agentic system, and user. FIG. 3. illustrates Sequence diagram for tool packaging, manifest creation, and optional re signing by the trusted authority.

DETAILED DESCRIPTION OF THE INVENTION: Before the present invention is described, it is to be understood that this invention is not limited to methodologies described, as these may vary as per the person skilled in the art. It is also to be understood that the terminology used in the description is for the purpose of describing the particular embodiments only and is not intended to limit the scope of the present invention. Throughout this specification, the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The use of the expression “at least” or “at least one” suggests the use of one or more elements or ingredients or quantities, as the use may be in the embodiment of the invention to achieve one or more of the desired objects or results. Various embodiments of the present invention are described below. It is, however, noted that the present invention is not limited to these embodiments, but rather the intention is that modifications that are apparent are also included. The present invention provides a trust framework system and method for secure, stateful interaction between agentic systems and third-party tools; wherein the system (100) comprises of a user (10), a root trust authority (RTA) (20), a customer registration module (CRM) (30), a trusted authority (40) and an agentic system (50) further comprising of an agentic system ingestion engine (ASIE) (51), an interactive session protocol (52), a framework API (53), an LLM orchestrator (54), a tool packaging and manifest generation module (55), a revocation service module (56), an execution engine (57), and a sandboxed tool (58).

10

According to an embodiment, the user (10) refers to human participant interacting with the agentic system (50) through at least one input unit via chat, voice, or other UI; the root trust authority also referred to as the hardware security module (HSM) holds the root private key (RPK) and generates a self-signed RootCertificate and signs all CustomerCertificates; the customer registration module (CRM) (30) generates a longterm customer key pair (CPK/CPU) where the CPK never leaves the customer’s secure environment, only CPU is transmitted to the RTA (20), and customer further registers its public key with the RTA (20) to receive a CustomerCertificate (CC); the trusted authority (40) is colocated with the RTA (20), that validates the customer signature and optionally resigns tool manifests to provide an additional trust anchor and thereby creating a certificate chain using the signatures such as RSASSA PSS SHA256 or ECDSA SHA256 for all certificates, manifests, and API messages; the agentic systems (AS) (50) further includes the LLMorchestrater platform that loads, verifies, and executes tools within a sandbox, and provides the framework API (53) for interactive sessions. In an embodiment of the invention, the customer registration module (CRM) (30) employs a customer registration process wherein the customer generates a customer key pair (CPK/CPU) locally. Then the customer logs in to the root trust authority (RTA) (20) which validates the user (10) or organizer via KYC or email, whereafter RTA (20) creates a customer certificate (CC) that considers the customer id, timestamp, org_id, public key, etc.; followed by signing the CC using a root private key (RPK) to thereby providing a signed customer certificate. The customer then stores the customer certificate and retains the CPK privately. The customer certificate is later used to verify tool manifests and to establish a trust chain. In a next embodiment of the invention, the tool packaging and manifest generation module (55) enables the user (10) to input in the form of an Artifact A (binary, container, zip), customer private key (CPK) or optional trusted authority (TA) (40); wherein the module enables the artifact Hash and enables manifest construction, followed by applying customer signature, an then by trusted authority (TA) (40) re-sign to add extra trust, finally providing an output in the form of Signed TM (JSON) and Artifact A. The manifest binds the artifact’s immutable hash to declared capabilities; any alteration of the artifact invalidates the manifest signature.

11

In a next embodiment, revocation service module (56) is configured to store the signed revocation list (SRL) which is a JSON array of revoked identifiers. The agentic system (50) fetches the latest SRL before any ingestion or execution step and rejects any identifier appearing in the list. Further, the agentic system ingestion engine (ASIE) (51) is configured for validation and registration that enables ingestion of tools by loading root certificate (selfsigned) from secure store, verifying TM signature using RPK or CPU, computing a hashtag, retrieving latest SRL, creating a sandbox with minimal OS image, POSIX capabilities limited to TM.requiredScopes, and file system read only except a per session `/tmp/state` directory, and registering tool in AS registry. If any step fails, the ingestion is aborted and a security incident event is logged. The Signed Revocation List (SRL) is signed with the RPK and refreshed every 24 hours. The AS caches the SRL and validates the signature before each ingestion or session start. Revocation can be triggered by compromise of a customer’s private key, discovery of a malicious artifact, or policy changes that invalidate a previously granted scope; as each manifest contains a kid, revoking that identifier instantly disables the tool across all agents without requiring redeployment. In a next embodiment of the invention, the interactive session protocol (52) is stateless from the viewpoint of the AS where each message carries its own authentication, but stateful for the tool via the encrypted session state store. The interactive session protocol (52) creates a globally unique session identifier (SID) for each userinitiated interaction; derives a SessionKey from the RPK and the SID using HKDFExtract; derives a StateEncryptionKey from the SessionKey using HKDFExpand; encrypts a mutable JSONstructured sessionstate store with the StateEncryptionKey; and packages the encrypted state together with the user’s naturallanguage request into a signed ToolRequest message delivered to the trusted tool. In a next embodiment of the invention, the agentic system (50) includes a sandbox configured for tool processing; wherein the sandbox executes pre-defined instructions by any trusted tool. The sandbox is instantiated per tool using a lightweight virtualisation technology (e.g., gVisor, Firecracker, or Kata Containers). Further, the clarification loop is enabled when the AS receives a ToolClarify message. The system then extracts the question, presents it to the user (10), collects the answer A, and constructs a new ToolRequest with the same SID, the user’s answer is placed in user_input, and the unchanged encrypted state. The clarification loop may repeat

12

arbitrarily many times until the tool emits a ToolResult or ToolError. When the AS receives tool result, it decrypts session_state for audit, and sends final answer to user (10). AS includes the tools such as frameworkAPI (53) /session/end (signed, HMAC protected). All messages are signed with the SessionKey derived from the SID, guaranteeing message integrity, origin authentication, and replay protection (nonce uniqueness is enforced by the AS). In yet a next embodiment of the invention, the large language model (LLM) orchestrator (54) employs a method to conduct a multiturn, stateful conversation with a thirdparty tool, the method comprising: (a) receiving a user (10) request; (b) creating a Session Identifier (SID); (c) encrypting an empty JSON state object with a key derived from the tool identifier; (d) delivering a signed ToolRequest containing the user (10) request and the encrypted state to the tool; (e) receiving from the tool either a ToolClarify message containing a question or a ToolResult message containing a final answer; (f) presenting any question to the user (10), collecting the user’s answer, and looping back to step d with the same SID until a ToolResult is received; and (g) delivering the final answer to the user (10) and terminating the session. In a preferred embodiment of the invention, the system employs a method for secure, stateful interaction between agentic systems (50) and third-party tools which comprises the steps of; - submitting a natural-language request (e.g., “book a flight”) by the user (10) to the LLM orchestrator (54); - running internal reasoning or function-calling model by the LLM orchestrator (54) to understand the user (10) request; - determining the appropriate tool (e.g., ToolX) by the LLM orchestrator (54) to fulfil the request; - preparing a ToolRequest payload by the LLM orchestrator (54) with the payload having a toolID, a user_input, a SID, and an encryptedState (if any); - sending the ToolRequest to the execution engine (57);

13

- ingesting the ToolRequest and forwarding it to the trusted authority (TA) (40) for validation; - undergoing a multi-step verification by the trusted authority (TA) (40) including verifying the root ↔ customer ↔ tool manifest signature chain, - checking the signed revocation list (SRL) to ensure the tool has not been revoked; - computing the SHA-256 hash of the artifact and comparing it to manifest.artifactHash; - returning the IngestionResult to the execution engine (57) with a prompt message such as ok or error, and signedManifest; - registering a sandbox by the execution engine (57) using the verified signedManifest and required scopes; - applying OS-level restrictions derived from the scopes; - loading and verifying the tool artifact (e.g., Docker image or binary); - executing the tool inside the sandbox with user_input, SID, and encryptedState; - decrypting the state (if present) using a session key in the sandboxed tool (58); - running the business logic (e.g., calling an external flight API) and producing a result in JSON format by the sandboxed tool (58); - sending a ToolResponse with result (JSON), updated encryptedState (if applicable) and SID, back to the execution engine (57); - forwarding the ToolResponse by the execution engine (57) to the LLM; - merging the result into the existing conversation contex by the LLM orchestrator (54); - responding to the user (10) with a final answer (e.g., "Your flight is booked"). In yet a next embodiment of the invention, the system employs an optional workflow for secure stateful interaction wherein the system requires clarification. The optional workflow comprises the steps of: - requesting clarification by sending a ToolClarify(question, SID, encryptedState) by the sandboxed tool (58) to the execution engine (57); - forwarding the clarification question by the execution engine (57) to the LLM orchestrator (54); - prompting the user (10) for input by the LLM orchestrator (54) such that the prompt depicts “Please provide: <question>”;

14

- providing a clarification answer by the user (10) to the LLM orchestrator (54); - creating a new ToolRequest by the LLM orchestrator (54) using the answer, SID, and encryptedStat and sending it to the execution engine (57); - re-executing the tool with the clarified input by the execution engine (57) and sending it to the sandboxed tool (58); - processing the updated request by the sandboxed tool (58) and producing a new result JSON; - sending the updated ToolResponse to the execution engine (57); - forwarding the new response by the execution engine (57) to the LLM orchestrator (54); - merging the new result by the LLM orchestrator (54) and responding to the user (10) with a final answer. According to yet another embodiment of the invention, the system and method of the present invention provides significant advantages including: - The protocol guarantees that only the trusted tool can decrypt its own session state, - cryptographic provenance; that the certificate chain guarantees that only a tool whose artifact hash matches the signed manifest, and whose manifest is signed by a valid customer key (or re-signed by the root), can be loaded; - fine grained capability control; that the declared scopes are enforced automatically by the sandbox, eliminating the need for manual IAM policy updates; - stateful multi turn interaction; that the encrypted per session state enables tools to retain context across user turns while keeping the raw user utterances hidden from the tool; - dynamic distrust; wherein the signed revocation list allows immediate revocation of compromised keys or malicious tools without service interruption; - scalable on boarding; such that the new customers obtain certificates via automated registration; tools are packaged and signed locally, requiring no human in the loop verification; and - the LLM independence; wherein the Framework API is generic; and any agentic system, regardless of underlying model, can adopt the same trust framework. While considerable emphasis has been placed herein on the specific elements of the preferred

15

embodiment, it will be appreciated that many alterations can be made and that many modifications can be made in preferred embodiment without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation. , Claims:CLAIMS: 1. A trust framework system and method for secure, stateful interaction between agentic systems and third-party tools; wherein the system comprises of a user (10), a root trust authority (RTA) (20), a customer registration module (CRM) (30), a trusted authority (40) and an agentic system (50) further comprising of an agentic system ingestion engine (ASIE) (51), an interactive session protocol (52), a framework API (53), an LLM orchestrator (54), a tool packaging and manifest generation module (55), a revocation service module (56), an execution engine (57), and a sandboxed tool (58);

characterized in that: the user (10) refers to human participant interacting with the agentic system (50) through at least one input unit via chat, voice, or other UI; the root trust authority also referred to as the hardware security module (HSM) holds the root private key (RPK) and generates a self-signed RootCertificate and signs all CustomerCertificates; the customer registration module (CRM) (30) generates a longterm customer key pair (CPK/CPU) where the CPK never leaves the customer’s secure environment, only CPU is transmitted to the RTA (20), and customer further registers its public key with the RTA (20) to receive a CustomerCertificate (CC); the trusted authority (40) is colocated with the RTA (20), that validates the customer signature and optionally resigns tool manifests to provide an additional trust anchor and thereby creating a certificate chain using the signatures for all certificates, manifests, and API messages; and the agentic systems (AS) (50) further include the LLMorchestrater platform that loads, verifies, and executes tools within a sandbox, and provides the framework API (53) for interactive sessions.

17

2. The system as claimed in claim 1, wherein the customer registration module (CRM) (30) employs a customer registration process thereby generating a customer key pair (CPK/CPU) locally; logging in to the root trust authority (RTA) (20); validating the user (10) or organizer via KYC or email, creating a customer certificate (CC) by RTA (20) by considering the customer id, timestamp, org_id or public key; signing the CC using a root private key (RPK); providing a signed customer certificate; storing the customer certificate and retaining the CPK privately.

3. The system as claimed in claim 1, wherein the tool packaging and manifest generation module (55) enables the user (10) to input in the form of an Artifact A (binary, container, zip), customer private key (CPK) or optional trusted authority (TA) (40); enabling the artifact Hash and manifest construction; applying customer signature; re-signing by the trusted authority (TA) (40) to add extra trust thereby providing an output in the form of Signed TM (JSON) and Artifact A. 4. The system as claimed in claim 1, wherein the revocation service module (56) is configured to store the signed revocation list (SRL) which is a JSON array of revoked identifiers; wherein the revocation is triggered by compromise of a customer’s private key, discovery of a malicious artifact, or policy changes that invalidate a previously granted scope; such that revoking that identifier instantly disables the tool across all agents without requiring redeployment. 5. The system as claimed in claim 1, wherein the agentic system (50) fetches the latest SRL before any ingestion or execution step and rejects any identifier appearing in the list; wherein the agentic system ingestion engine (ASIE) (51) is configured for validation and registration that enables ingestion of tools by loading root certificate (selfsigned) from secure store, verifying TM signature using RPK or CPU, computing a hashtag, retrieving latest SRL, creating a sandbox and registering tool in AS registry; such that on failure of any step, the ingestion is aborted and a security incident event is logged.

18

6. The system as claimed in claim 1, wherein the LLM orchestrator (54) of the agentic system (50) employs a method to conduct a multiturn, stateful conversation with a thirdparty tool, comprising the steps of; (a) receiving a user (10) request; (b) creating a Session Identifier (SID); (c) encrypting an empty JSON state object with a key derived from the tool identifier; (d) delivering a signed ToolRequest containing the user (10) request and the encrypted state to the tool; (e) receiving from the tool either a ToolClarify message containing a question or a ToolResult message containing a final answer; (f) presenting any question to the user (10), collecting the user’s answer, and looping back to step d with the same SID until a ToolResult is received; and (g) delivering the final answer to the user (10) and terminating the session.

7. A method for secure, stateful interaction between agentic systems (50) and third-party tools which comprises the steps of; - submitting a natural-language request by the user (10) to the LLM orchestrator (54); - running internal reasoning or function-calling model by the LLM orchestrator (54) to understand the user (10) request; - determining the appropriate tool by the LLM orchestrator (54) to fulfil the request; - preparing a ToolRequest payload by the LLM orchestrator (54) with the payload having a toolID, a user_input, a SID, and an encryptedState; - sending the ToolRequest to the execution engine (57); - ingesting the ToolRequest and forwarding it to the trusted authority (TA) (40) for validation; - undergoing a multi-step verification by the trusted authority (TA) (40) including verifying the root ↔ customer ↔ tool manifest signature chain, - checking the signed revocation list (SRL) to ensure the tool has not been revoked; - computing the SHA-256 hash of the artifact and comparing it to manifest.artifactHash; - returning the IngestionResult to the execution engine (57) with a prompt message such as ok or error, and signedManifest;

19

- registering a sandbox by the execution engine (57) using the verified signedManifest and required scopes; - applying OS-level restrictions derived from the scopes; - loading and verifying the tool artifact; - executing the tool inside the sandbox with user_input, SID, and encryptedState; - decrypting the state using a session key in the sandboxed tool (58); - running the business logic and producing a result in JSON format by the sandboxed tool (58); - sending a ToolResponse with result (JSON), updated encryptedState and SID, back to the execution engine (57); - forwarding the ToolResponse by the execution engine (57) to the LLM; - merging the result into the existing conversation contex by the LLM orchestrator (54); - responding to the user (10) with a final answer.

8. The method as claimed in claim 7, wherein the system employs an optional workflow for wherein the system requires clarification comprising the steps of; - requesting clarification by sending a ToolClarify(question, SID, encryptedState) by the sandboxed tool (58) to the execution engine (57); - forwarding the clarification question by the execution engine (57) to the LLM orchestrator (54); - prompting the user (10) for input by the LLM orchestrator (54) such that the prompt depicts “Please provide: <question>”; - providing a clarification answer by the user (10) to the LLM orchestrator (54); - creating a new ToolRequest by the LLM orchestrator (54) using the answer, SID, and encryptedStat and sending it to the execution engine (57); - re-executing the tool with the clarified input by the execution engine (57) and sending it to the sandboxed tool (58); - processing the updated request by the sandboxed tool (58) and producing a new result JSON; - sending the updated ToolResponse to the execution engine (57);

20

- forwarding the new response by the execution engine (57) to the LLM orchestrator (54); - merging the new result by the LLM orchestrator (54) and responding to the user (10) with a final answer.