Zero Trust for Agents: Implementing Context Lineage in the Enterprise Data Mesh

Challenge: When Agentic Bots Become Primary Data Reader

In large data platforms, AI agents now execute more data queries than human users. For teams that are running thousands of internal services, it is very common to have hundreds or thousands of agentic bots querying data: a "Supply Chain Optimizer" reading manufacturing logs, a "System Quality Analyst" agent querying usage metrics, or a "Sales Forecaster" aggregating regional sales data, finally passing or interacting with some models.

In a decentralized data mesh, domain owners need a way to detect whether an agent that they allowed to read critical data has been altered or compromised since its identity was issued. In such cases, mTLS authenticates the caller service but provides no details about the agent's prior actions or execution context, such as which model or service it is, or what actions it has performed with the data in the past.

I implemented the research paper, 'Context Lineage Assurance for Non-Human Identities in Critical Multi-Agent Systems' (2025) (arXiv:2509.18415), which proposes a solution: cryptographic Action Lineage. In the following sections, I explain how I implemented this specification in a large-scale environment.

Core Concept: Binding Identity to Historical Behavior

This paper proposes that an agent's identity must be bound to its historical actions. It introduces two concepts:

1. Agent Card: A verifiable credential containing the agent's static metadata.
2. Context Lineage or Agent Audits: A tamper-evident log of the agent's past actions (e.g., "Deployed at 10:00 AM", "Accessed Public Data at 10:05 AM").

Critical systems require agents to present both their identity and their cryptographic proof of an intact action history.

Implementation: The "iMesh" Trust Layer

In this implementation, we used an approach of sidecar-based lineage architecture as it allows governance policies to be enforced at request time without modifying agent code.

1. Components Implemented

• Agent identity provider: A central service that issues Agent Identity and maintains the root hashes of the Action Logs.
• Agent sidecar: A per-pod proxy that records outbound requests and maintains a local Merkle tree of actions.
• Policy service: A policy enforcement point sitting in front of every Data Product (e.g., Snowflake, Spark, or internal APIs).

2. Protocol and Data Flow

When a "analytics agent" (Consumer) tries to read data from the "User Privacy Domain" (Provider):

Handshake: Agent Sidecar connects to the Policy Service.

Challenge: The policy service challenges the agent to present both its identity credential and a verifiable lineage proof.

Verification: The Policy Service checks:

• Is the signature valid? (Identity check)
• Does the Merkle proof match the latest root hash published by the Authority? (Integrity check)
• Does the lineage include actions that violate policy, such as outbound connections to untrusted networks?

Access: If clean, the data pipe opens.

Implementation Details: Merkle Log

In our data mesh, performance is critical. We cannot ask a central server to verify every request. This paper suggests using Merkle consistency proofs for efficient, decentralized verification.

Here is a pseudocode showing how a data service might verify an incoming agent lineage:

import hashlib
from typing import List

class LineageVerifier:
    def __init__(self, trusted_authority_public_key):
        self.authority_key = trusted_authority_public_key

    def verify_agent_access(self, agent_card: dict, lineage_proof: List[str], latest_action: str) -> bool:
        """
        Verifies an agent's request to access a Data Product.
        """
        # Step 1: Verify the Agent Card Identity (Standard PKI)
        if not self.verify_signature(agent_card, self.authority_key):
            print("Access Denied: Invalid Agent Identity")
            return False

        # Step 2: Verify Lineage Integrity (The 'Paper' Innovation)
        # Reconstruct the Merkle Root from the provided proof and latest action
        calculated_root = self.compute_merkle_root(latest_action, lineage_proof)
        
        # Check if this root is anchored on the public ledger
        # This proves the agent hasn't 'deleted' a past bad action from its history
        if not self.is_root_anchored(agent_card['id'], calculated_root):
            print("Access Denied: Agent Lineage does not match the public ledger.")
            return False
            
        # Step 3: Semantic Policy Check
        # Check the lineage for prohibited behaviors (e.g., data exfiltration risks)
        if self.detect_toxic_history(lineage_proof):
             print("Access Denied: Agent history contains policy violations.")
             return False

        print(f"Access Granted to Agent: {agent_card['agent_name']}")
        return True

    def compute_merkle_root(self, leaf, proof):
        # ... standard Merkle hashing logic ...
        pass

Governance Implications of Action Lineage

For a company dealing with massive scale and sensitive user data, this architecture provides three operational benefits:

• Auditability: If data leaks, you don't just know who queried it. You can traverse the Merkle log to see exactly what that agent did before the query.
• Containment: If an agent is compromised (e.g., its code is injected with malware), its behavior changes. In this case, Lineage/Merkle root changes. The "Policy Service" sidecars at the Data Mesh layer will mathematically reject its requests because the proofs will fail, subsequent requests from the agent fail verification, effectively isolating it from protected data products.
• GDPR/privacy compliance: You can prove, cryptographically, that an agent accessing PII did not previously access a public internet gateway, enforcing a strict "gap" purely through software policy.

Conclusion

As we move from human-scale to agent-scale data consumption across almost every company/team, Agent Identity alone does not capture whether an agent's execution context has remained trustworthy over time. By implementing context lineage or audit traces, we turn our data mesh into a zero-trust environment where agents must prove not just who they are, but also that their identity and the sequence of actions remain intact and verifiable.

References

Malkapuram, S., et al. (2025). "Context Lineage Assurance for Non-Human Identities in Critical Multi-Agent Systems." arXiv:2509.18415.