Implementing the Agentic Trust Framework (ATF): Zomma's Playbook

Introduction

As this field of Agentic Trust evolves, we will constantly iterate and update our Playbook as we come across any counter-arguments that contradict our initial groundwork for an Agentic Trust Framework (ATF). Therefore, this Playbook is the version we're running with today, and we'll update as we go.

The question on authorisation, delegation, identity, safety and trust in the agentic world is gaining considerable attention, with multiple organisations driving up standards and implementations (Google, Microsoft, Huang et al., etc.).

I’ve taken a look at existing literature—which was obviously an arduous reading assignment in itself. The amount of rigour by some of these researchers, especially the ones who worked on the pre-print academic papers, is frankly quite admirable. Admittedly I’ve only managed quick passes a la academic paper-style reading.

Here is the summary table on prior art used as inspiration and reference for our decisions:

In summary, I largely concur with Microsoft saying that when you have a system that is probabilistic (in our case, an LLM and its derivatives), you can’t guard that with another input that is used to feed it (”pretty please, follow these rules”). This is probabilistic compounding. You need something deterministic, hard-coded even, as a measure to tamp down the probabilistic outputs of a model.

Prompt-level safety is not a control surface. It is a polite request to a stochastic system. OWASP LLM01:2025 states this explicitly: "it is unclear if there are fool-proof methods of prevention for prompt injection."

–– Microsoft Agentic Governance Toolkit (AGT)

And so, with Zomma, I think what we could do is to be informed by Microsoft’s architecture decision of having a guardrail layer that is essentially deterministic application code, along with ingress- and egress-firewalls.

Firstly, let’s start with the definitions to be used within Zomma’s operating context*:

1. Agent → context-bearing: context + model + instructions + tools
2. Effector → context-free, policy-gated (hands-and-legs): model+ instructions + tools

*definitions subject to change.

Our Agentic Trust Framework Playbook

Here's a simplified bird's eye view on what we've built into our system:

In the above diagram, you could see how we split our security concerns into four different bands, each answering the following questions:

1. Input assurance: “how do we ensure whatever’s coming into our system is safe?”
2. Governed reasoning: “how do we nudge our models’ reasoning in the right direction?”
3. Policy-mediated action: “how do we put in controls that allow/deny actions, and log it down for future audits?”
4. Isolated execution & output assurance: “how do we ensure data accuracy, separation and sanitisation of secrets?”

Input assurance

This is where input is sanitised before it gets into our system. We treat anything ingress with zero trust, verifying at each step. Thus, we’ve decided to incorporate a two-step parallel ensemble of deterministic screening, along with an input checks classifier. This helps to mitigate prompt-injection or context extraction from our systems.

In the space of deterministic prompt injection screening and MCP input checks, we’ve decided to leverage on Microsoft’s production-grade expertise in their Agentic Governance Toolkit.

To further harden our system, we’ve also added in processes that alert us on malicious input and redact content as it’s streamed back as response to the user.

Governed reasoning

The AI agent reasons with least privilege, capabilities are explicitly granted from our pool of policies and deterministic capability (tool) allowlist. This is aligned to Microsoft’s AGT aforementioned principle that prompt-level safety is by no means a control surface.

Policy-mediated action

If our model reasons that an action needs to be done, we will gate each consequential action with policy gates before it happens. This involves our own allow-/deny-lists or one that requires a human approval.

Every action, authorisation and delegation is logged into our auditing capabilities. A work-in-progress is to explore using Merkle trees for action-sequence chains to improve auditability of agentic actions.

Isolated execution and output assurance

We’ve been using ephemeral instances (i.e., create instance → run task → kill) with network egress allowlists to carry out any task, which includes our computer-use tasks that forms the core of our business. This is especially important for separation of concerns.

Our outputs are also screened to ensure that any context isn’t extracted when it’s returned as a response. Of course, responses will be streamed midway, then redacted, as it’s server-side events, so we’re also thinking on the user interface aspect of this redaction.

Lastly, we know that human-in-the-loop should not be a feature to be marketed, but it is important that we assure our users that live observation and takeovers are encouraged for sensitive steps, as is the case of a pilot taking over control of an aircraft’s autopilot systems.

Open questions

There's still more rigorous work that needs to be done in Agentic Trust. Some questions that I’ve asked myself and others before—that I’m open to revisit based on the needs of various stakeholders are:

1. “Did this task execute faithfully as per instructions” → attestation
2. “Can we be sure the host machine is not compromised when it’s running the task set?” → instruction integrity
3. “Exactly who authorised this task? Can we be sure of it?” → identity
4. “When something did go wrong, which hop is responsible exactly?” → attribution
5. “How do we investigate ephemeral instances/tasks (i.e., our Effector) when things go wrong?” → liability

Future work

Future work centres on the tying the seams between our above-mentioned four security bands. I’d want to explore how we could:

1. ensure host attestation with a Trusted Enclave,
2. use SPIFFE for identifiers as our multiple task/instances architecture mimic distributed systems,
3. binding authority (”principal”) to the attested runtime, and;
4. federated scopes (e.g., cross-domain, cross-agent, cross-organisation).

The part that I keep returning to, is the question on: "which hop is responsible when something goes wrong?". I know finger-pointing is frowned upon in an engineer's blameless post-mortem culture. This is rightly so for people, but when operating environments are sensitive and the stakes are higher, I think it's worthy of deeper research on where the faults in our stars systems lie.

P.S.:

Recently, I came across a comment by a fellow developer in the Agentic Trust space on HackerNews, and thought I’d share:

The agent identity space needs more builders and more collaboration, not territorial claims over generic terms. If anyone working on this wants to compare architectures or find interop opportunities, I'm genuinely interested.

– Tymofii Pidlisnyi on https://news.ycombinator.com/item?id=47096131

Similarly, I think this space is going to be an exciting one to watch, and we should be open to more collaboration.

If you’re interested to connect, please reach out to me at hello@getzomma.com or er558@cornell.edu.

Thanks!