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.