{
  "source_file": "0930",
  "source_platform": "Hashnode",
  "author": "Jaival Suthar",
  "title_listed": "AgentGuard: Building a Trust Boundary for Agentic Execution",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://jaivalsuthar.hashnode.dev/agentguard-the-trust-boundary-for-agentic-execution",
  "publish_date": "2026-08-30",
  "corpus_stage": "",
  "notes": "",
  "id": "f8f2abe1d0f7",
  "collected_at": "2026-10-02T14:12:15",
  "title": "AgentGuard: AI Agent Security, Policy & Execution Assurance",
  "body_markdown": "AgentGuard: Building a Trust Boundary for Agentic Execution\nWhat if an AI agent says it succeeded, but the evidence says otherwise?\nUpdated\nAugust 30, 2026\n•\n16\nmin read\n•\nView as Markdown\nJ\nJaival Suthar\nI write technical articles that analyze real world engineering problems through the lens of production systems.\nMy work focuses on architectural tradeoffs, UI layer system design, performance optimization, and reliability patterns derived from shipping and maintaining scalable applications.\nAI agents are becoming increasingly capable of taking actions rather than simply generating text.\nThey can inspect systems, call tools, execute code, modify state, recover from failures, and interact with external services through protocols such as MCP.\nThat creates a problem that is different from ordinary application correctness.\nAn agent can say: \"I investigated the incident and fixed it.\"\nBut what actually happened?\nDid it call the right tool?\nDid the tool return what the agent claims?\nDid it execute code in the intended sandbox?\nDid it stay within its execution contract?\nDid a retry actually recover the operation?\nWas a dangerous action authorized?\nDid the action execute at all?\nAnd perhaps most importantly:\nCan I prove the answer without trusting the agent's own narrative?\nThat question became the foundation for\nAgentGuard\n.\nThe core idea is simple:\nAn agent's claim is not evidence. The execution trajectory is evidence.\nAgentGuard is a runtime trust and assurance layer for agentic systems.\nTrueForge\nprovides the execution runtime; AgentGuard sits around that execution to govern consequential actions, capture evidence, verify execution contracts, reason about recovery, and produce an auditable assurance result.\n🔗\nGitHub Repository:\nhttps://github.com/Jaival-Suthar/agentguard\nThe architectural boundary is deliberate:\nTrueForge owns execution. AgentGuard owns trust.\nThe problem: an agent saying \"done\" is not proof\nTraditional software gives us relatively clear sources of truth.\nA process exited with code\n0\n.\nA database transaction committed.\nA test passed.\nA request returned a particular response.\nAgentic systems introduce another layer between the system and the result: the model's interpretation of what happened.\nConsider an incident investigation agent.\nIt might:\nInvestigate incident\n       ↓\nRead incident state\n       ↓\nInspect logs\n       ↓\nRun analysis\n       ↓\nAttempt remediation\n       ↓\nReport success\nThe final response might confidently say:\nIncident resolved.\nBut the runtime could tell a different story:\nincident.lookup        ✓\nsandbox execution     ✓\nrollback requested    ✓\nrollback denied       ✓\nrollback executed     ✗\nverification          ✗\nThe agent's statement and the runtime trajectory are not equivalent.\nThat led to the central design principle behind AgentGuard:\nNever promote model narrative into runtime truth.\nThe verifier should establish facts from execution evidence. The assurance layer should summarize those facts.\nFrom agent execution to execution proof\nAgentGuard treats an agent run as a sequence of observable events rather than a final text response.\nA simplified execution might look like:\nAgent intent\n     ↓\nPolicy evaluation\n     ↓\nTool request\n     ↓\nTool execution\n     ↓\nTool result\n     ↓\nEvidence collection\n     ↓\nContract verification\n     ↓\nRecovery if necessary\n     ↓\nIndependent verification\n     ↓\nAssurance verdict\nThis gives the system several distinct questions to answer.\nWhat was the agent trying to do?\nThe execution intent and requested action.\nWas it allowed?\nThe policy decision at the execution boundary.\nWhat actually happened?\nThe runtime and tool evidence.\nDid the execution satisfy its contract?\nThe execution verifier.\nDid recovery actually work?\nThe resulting trajectory and independent verification.\nWhat can we prove?\nThe final Assurance Artifact.\nKeeping these questions separate is one of the most important architectural decisions in AgentGuard.\nExecution contracts: defining what \"success\" means\nA tool call succeeding is not necessarily an execution succeeding.\nA recovery API returning successfully is not necessarily a recovered system.\nAnd a model claiming success is certainly not sufficient evidence.\nAgentGuard therefore uses\nexecution contracts\nto define the conditions that must be satisfied for a run to be considered valid.\nA contract can express requirements around:\nexpected actions\npermitted retries\nrequired evidence\nexecution outcomes\ntarget identity\nrecovery behavior\nInstead of asking: Did the agent run?\nAgentGuard asks: Did the execution satisfy the declared contract?\nThat distinction becomes particularly important when failures and retries enter the picture.\nEvidence is the source of truth\nOne of the most important parts of AgentGuard is the evidence verification layer.\nRuntime events are normalized into a common execution vocabulary so that the verifier can reason about the execution without depending on every underlying runtime detail.\nConceptually:\nTrueForge evidence\n       ↓\nObservation normalization\n       ↓\nEvent correlation\n       ↓\nEvidence verification\n       ↓\nContract verification\n       ↓\nPASS / WARN / FAIL\nThe verifier correlates things such as:\nTOOL_CALL\nTOOL_RESULT\nSANDBOX\nEXECUTION\nFAILURE\nRECOVERY\nPOLICY\nAPPROVAL\nThe important part is not merely recording those events.\nIt is establishing their relationships.\nFor example:\nWhich action requested this result?\nWhich tool produced it?\nWhich result belongs to which call?\nWas that attempt successful?\nWas it a retry?\nDoes the evidence correspond to the required target?\nDoes the observed trajectory satisfy the contract?\nWithout that provenance, an assurance system can become confidently wrong.\nThat is why AgentGuard deliberately treats:\nAgent output ≠ Ground truth\nGround truth comes from the execution evidence.\nRetries are part of the truth\nRetries make execution verification substantially harder.\nConsider:\nAttempt 1 → FAIL\nAttempt 2 → SUCCESS\nThat is not the same execution outcome as:\nAttempt 1 → FAIL\nAttempt 2 → FAIL\nThe first attempt should not disappear merely because a later attempt succeeded.\nAt the same time, a successful retry should not be ignored simply because the first attempt failed.\nAgentGuard therefore reasons about the\ntrajectory\nrather than treating an action as a single static event.\nThis is also an area where Qodo's review was particularly valuable. It identified correctness problems around retry/evidence correlation and helped expose cases where the verifier could select the wrong evidence rather than correctly associating a successful retry with the contract requirement.\nThat resulted in both implementation changes and stronger tests.\nFor an assurance system, this matters enormously.\nA verifier that mishandles retries can report the wrong truth while still appearing perfectly deterministic.\nSandbox execution must be proven too\nThe same principle applies to sandboxed execution.\nAn event saying: sandbox started\nis not equivalent to proving: the intended computation executed successfully\nAgentGuard therefore distinguishes between an invocation and its verified outcome.\nThe broader principle is:\nAn observation about an action is not automatically proof of its result.\nThis sounds obvious.\nIn practice, maintaining that distinction across an event pipeline, runtime adapter, verifier, recovery system, and UI is surprisingly easy to get wrong.\nThat is why the evidence model is deliberately explicit.\nPolicy before execution\nPost-execution verification is only half of the problem.\nA trustworthy agent system also needs to answer:\nWhat if the action should never execute in the first place?\nAgentGuard therefore introduces a policy boundary at the MCP execution layer:\nThe critical invariant is:\nIf an action is blocked or approval is denied, the real executor must never be called.\nThis changes AgentGuard from a purely observational system into a control boundary.\nIt can now answer both: Was the action allowed to execute?\nand: Did the action execute correctly?\nThose are different questions.\nAnd for consequential agent actions, both matter.\nHuman approval is a real execution boundary\nSuppose an agent requests: rollback_incident\nAgentGuard determines: APPROVAL_REQUIRED\nThe human denies it.\nA weak implementation might only show:\n❌ Denied\nThe stronger guarantee is:\nAgent request\n      ↓\nPolicyGate\n      ↓\nAPPROVAL_REQUIRED\n      ↓\nHuman DENY\n      ↓\nAPPROVAL_DENIED\n      ↓\nREAL EXECUTOR INVOCATIONS = 0\nThat final line is the important part.\nThe dangerous operation never ran.\nThis is the difference between displaying a security decision and enforcing one.\nRecovery is not just retrying\nFailures are inevitable in real agentic systems.\nThe interesting question is what happens next.\nAgentGuard treats recovery as a bounded execution trajectory:\nAttempt 1\n   ↓\nFAIL\n   ↓\nRecovery decision\n   ↓\nAttempt 2\n   ↓\nObserve\n   ↓\nVerify\nRecovery is constrained by the execution contract rather than becoming an uncontrolled retry loop.\nMore importantly:\nA recovery action is not proof of recovery.\nThe system must observe the resulting execution and independently verify that the expected state has actually been restored.\nThat gives the complete lifecycle:\nFailure\n  ↓\nRecovery\n  ↓\nRe-execution\n  ↓\nObservation\n  ↓\nIndependent verification\nOnly then should recovery contribute to the final assurance result.\nThe Assurance Artifact\nOnce AgentGuard had policy, execution, contract, evidence, and recovery signals, there was a dangerous temptation:\nLet the UI combine them and decide what happened.\nI deliberately avoided that.\nInstead, AgentGuard has a deterministic\nAssurance Artifact\nthat acts as the authoritative composition layer.\nConceptually:\nThe artifact records the relevant lifecycle state, component checks, summaries, recovery information, and final verdict.\nThe important boundary is:\nThe UI does not decide whether an execution passed. The artifact does.\nThis makes the artifact independently inspectable and prevents different presentation surfaces from inventing different versions of the truth.\nDeterminism matters\nAn assurance result should not depend on incidental runtime state.\nFor identical inputs:\nsame evidence\n     +\nsame contract\n     +\nsame policy\n     ↓\nsame assurance result\nThis sounds straightforward, but even seemingly harmless details can break it.\nFor example, allowing an Assurance Artifact timestamp to silently default to the current clock means the same input can produce different artifacts.\nQodo caught this class of issue during review.\nThe fix was to make the relevant artifact inputs explicit and deterministic.\nThat matters because reproducibility is part of trust.\nIf two independent verifiers receive the same evidence, they should be able to arrive at the same logical conclusion.\nQodo: challenging the trust boundary itself\nQodo\nbecame especially useful on AgentGuard because the hardest bugs were not simple syntax errors or obvious failures.\nThey were\ncorrectness-of-the-verifier\nproblems.\nThe reviews challenged assumptions around:\nretry semantics\nevent identity\nevidence correlation\npolicy provenance\nrecovery state\ndeterministic artifacts\nverdict rendering\nsecurity boundaries\nOne particularly important finding involved the Assurance Artifact receiving:\npolicyVerdict: \"ALLOW\"\nfrom an integration path rather than deriving that decision from the actual deterministic policy evaluator.\nThat created the possibility of an artifact saying:\nPolicy: PASS\nwithout actually evaluating the policy.\nQodo caught the issue.\nThe implementation was changed so that the real policy evaluation became the source of the artifact's policy result.\nAnother review caught a recovery-state inconsistency where an existing successful recovery result could be discarded during error handling and replaced with an inconsistent state.\nAgain, the fix was not merely cosmetic.\nThe system was changed to preserve the actual execution trajectory.\nQodo also identified additional issues around event identity and correlation, including cases where ID-less events could accidentally share state.\nThat matters because incorrect correlation in an assurance system is much worse than an ordinary application bug.\nIt can produce a\ncredible but false proof\n.\nThat is exactly the class of failure AgentGuard is supposed to prevent.\nSo the role of Qodo was not:\n\"Qodo wrote my code.\"\nIt was:\nQodo continuously challenged whether the code's claims were actually supported by its implementation.\nFor a project whose purpose is proving claims about agent execution, that was an unusually strong fit.\nTesting the trust model\nThe implementation is backed by\n100+ passing test cases\ncovering the core execution, verification, policy, recovery, evidence, assurance, and integration behavior.\nThe important part is not simply the number.\nThe tests exercise the failure modes that matter to a trust boundary:\nAllowed action\nBlocked action\nApproval required\nApproval denied\nMissing approval handler\nSuccessful execution\nFailed execution\nSuccessful retry\nExhausted retry budget\nEvidence mismatch\nInvalid evidence\nSandbox verification\nRecovery success\nRecovery failure\nAssurance precedence\nDeterministic artifact generation\nMCP integration\nThat gives AgentGuard a much stronger foundation than a demo where only the happy path is exercised.\nThe goal is not to prove that every possible agent behavior is safe.\nThe goal is to make the behavior inside the defined assurance boundary deterministic, testable, and explainable.\nThe Assurance Console is a proof surface\nOnce the backend could produce an authoritative assurance artifact, a human still needed a way to inspect it.\nThat is where the Assurance Console comes in.\nThe live architecture is:\nTrueForge Runtime\n       ↓\nRun Evidence\n       ↓\nLive Store\n       ↓\nREST / SSE API\n       ↓\nAssurance Console\nThe console exposes:\nrun identity\nconnection state\nsemantic execution timeline\npolicy decisions\ntool calls\nevidence\nrecovery\nassurance artifact\nfinal verdict\nBut it does not independently decide the verdict.\nThat distinction is critical.\nA dashboard can make almost anything look trustworthy.\nAgentGuard instead tries to make the dashboard a projection of something that has already been verified.\nThe console asks:\nWhat happened?\nThe verifier asks:\nCan the evidence prove the required facts?\nThe policy layer asks:\nWas the action permitted?\nThe contract asks:\nWhat should have happened?\nThe Assurance Artifact asks:\nWhat does all of that establish?\nThose questions remain separate.\nThe architecture is deliberately domain-independent\nThe current demonstration uses incident investigation because it provides a concrete workload for demonstrating the system.\nBut AgentGuard's underlying trust model is not fundamentally about incidents.\nIt is about generic execution primitives:\nActor\nAction\nTool\nInput\nOutput\nResource\nState\nInvariant\nPolicy\nEvidence\nDecision\nApproval\nFailure\nRecovery\nThat means the same assurance machinery could eventually be applied to:\nDevOps agents\nFinance agents\nDatabase agents\nGitHub agents\nResearch agents\nCloud agents\nCustomer-support agents\nBrowser agents\nThe domain changes.\nThe assurance model should not.\nThat is why normalized events, contracts, policy decisions, evidence, and assurance artifacts are kept separate from the specific workload.\nWhy MCP is an important boundary\nAgent systems increasingly interact with external capabilities through standardized tool interfaces.\nMCP provides a useful boundary for AgentGuard because the system can observe a meaningful transition:\nAgent\n  ↓\nMCP\n  ↓\nTool request\n  ↓\nPolicy\n  ↓\nTool execution\n  ↓\nTool result\nInstead of deeply coupling the assurance layer to the internals of every agent framework, AgentGuard can reason about the execution boundary.\nTrueForge provides the current runtime integration.\nThe longer-term architectural direction is to make the assurance machinery increasingly independent of the underlying agent runtime.\nThe UI is not the product\nThis is worth stating explicitly.\nAgentGuard is not a dashboard for TrueForge.\nThe UI is simply how a human inspects the evidence.\nThe actual product idea is the trust boundary underneath it:\nIntent\n  ↓\nPolicy\n  ↓\nExecution\n  ↓\nEvidence\n  ↓\nContract\n  ↓\nRecovery\n  ↓\nVerification\n  ↓\nAssurance\nThe console makes that lifecycle visible.\nIt does not define it.\nWhat AgentGuard Is Designed to Prove\nAssurance systems become less credible when they claim too much.\nAgentGuard is not intended to be:\nanother agent runtime\na replacement for TrueForge\na complete enterprise IAM platform\nan autonomous policy authorizer\na universal verifier for every agent framework\na claim of cryptographically tamper-proof evidence\nThe current system focuses on a narrower and more defensible problem:\nControl consequential agent actions, capture execution evidence, and deterministically establish what that evidence proves.\nThat boundary is intentional.\nWhat I learned\nRuntime evidence is more valuable than model narrative\nThe model knows what it intended to do.\nThe runtime knows what happened.\nThose are not the same thing.\nVerification needs provenance\nIt is not enough to find:\nincident_id = INC-042\nsomewhere in the output.\nYou need to know:\nWhich action requested it?\nWhich tool produced it?\nWhich result belongs to that call?\nWas the result successful?\nCan the evidence be correlated exactly?\nOtherwise the verifier can become confidently wrong.\nRetries change the meaning of evidence\nA failed attempt followed by a successful attempt is different from two failed attempts.\nThe trajectory matters.\nRecovery must end in verification\nA repair action returning successfully is not proof that the system was repaired.\nThe resulting state must be independently evaluated.\nSecurity boundaries must fail closed\nWhen AgentGuard cannot establish that an action is authorized, the safe answer is not:\nprobably okay\nIt is:\nnot authorized\nThe same principle applies to evidence.\nWhen AgentGuard cannot establish that an outcome happened, it should not manufacture confidence.\nFuture work\nThe current architecture leaves a few natural directions open.\nModel-agnostic runtime adapters\nExtend beyond the current TrueForge integration toward additional agent runtimes and generic MCP environments.\nEnvironment discovery\nAllow AgentGuard to identify potentially dangerous or state-changing tools and propose candidate policies for operator validation.\nThe important constraint is that adaptive discovery should\npropose\n, not silently rewrite the deterministic trust core.\nExecution lineage\nFor long-running agents, reconstruct the complete lineage:\nTask\n ↓\nPlan\n ↓\nTool calls\n ↓\nRetries\n ↓\nCode execution\n ↓\nState changes\n ↓\nVerification\n ↓\nFinal claim\nThat could enable a particularly useful assurance capability:\nThe agent's final claim is not supported by its execution evidence.\nThe bigger idea\nAgent systems are moving from:\ngenerate text\ntoward:\nobserve\nreason\nact\nretry\nmodify\nrecover\nAs agents become more capable, capability alone becomes less interesting.\nThe harder question becomes:\nHow do we trust the execution?\nThat is the problem AgentGuard explores.\nThe architecture is intentionally simple:\nAgent\n  ↓\nIntent\n  ↓\nPolicy\n  ↓\nExecution\n  ↓\nEvidence\n  ↓\nContract\n  ↓\nRecovery\n  ↓\nVerification\n  ↓\nAssurance\nAnd the core philosophy is even simpler:\nDon't trust what the agent says it did. Prove what actually happened.\nThat is why AgentGuard sits alongside an agent runtime rather than trying to replace it.\nTrueForge makes the agent capable of acting. AgentGuard makes those actions observable, governable, verifiable, and accountable.\nFinal takeaway\nThe interesting question for agentic systems is no longer only:\n\"What can the agent do?\"\nIt is increasingly:\n\"What can we prove the agent actually did?\"\nAgentGuard is an attempt to build that missing layer.\nA layer where authorization is enforced before consequential execution, runtime behavior becomes evidence, execution contracts define success, recovery is bounded and verified, and the final result is represented by a deterministic assurance artifact.\nBecause when an agent says:\n\"I fixed it.\"\nthe most important question is not whether the answer sounds convincing.\nIt is:\nWhat evidence proves it?\nThat is what AgentGuard is built to answer.\n#\nai-agents\n#\nai\n#\nmcp\n#\nagentic-ai\n#\ndeveloper-tools",
  "metadata": {
    "title": "AgentGuard: AI Agent Security, Policy & Execution Assurance",
    "description": "AgentGuard builds a trust boundary for AI agents: enforce policy before execution, verify runtime evidence, and prove what actually happened.",
    "keywords": null,
    "author": null,
    "og:title": "AgentGuard: AI Agent Security, Policy & Execution Assurance",
    "og:description": "AgentGuard builds a trust boundary for AI agents: enforce policy before execution, verify runtime evidence, and prove what actually happened.",
    "og:url": "https://jaivalsuthar.hashnode.dev/agentguard-the-trust-boundary-for-agentic-execution",
    "og:site_name": "Jaival Suthar | Engineering Portfolio",
    "og:image": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/f0095dc0-6f8e-4ea8-9872-67b6fe2cffa6.png",
    "og:image:width": "1200",
    "og:image:height": "630",
    "og:type": "article",
    "twitter:card": "summary_large_image",
    "twitter:creator": "https://x.com/Jaival_Suthar",
    "twitter:title": "AgentGuard: AI Agent Security, Policy & Execution Assurance",
    "twitter:description": "AgentGuard builds a trust boundary for AI agents: enforce policy before execution, verify runtime evidence, and prove what actually happened.",
    "twitter:image": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/f0095dc0-6f8e-4ea8-9872-67b6fe2cffa6.png",
    "article:published_time": "2026-08-30T15:26:09.968Z",
    "article:modified_time": "2026-08-30T15:26:09.968Z",
    "article:author": "https://jaivalsuthar.hashnode.dev/@JaivalSuthar"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [
    {
      "file": "attachments/f8f2abe1d0f7/code/body-000.txt",
      "chars": 147,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-001.txt",
      "chars": 145,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-002.txt",
      "chars": 241,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-003.txt",
      "chars": 171,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-004.txt",
      "chars": 73,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-005.txt",
      "chars": 140,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-006.txt",
      "chars": 83,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-007.txt",
      "chars": 83,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-008.txt",
      "chars": 83,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-009.txt",
      "chars": 23,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-010.txt",
      "chars": 328,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-011.txt",
      "chars": 111,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-012.txt",
      "chars": 107,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-013.txt",
      "chars": 127,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-014.txt",
      "chars": 77,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-015.txt",
      "chars": 102,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-016.txt",
      "chars": 22,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-017.txt",
      "chars": 153,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-018.txt",
      "chars": 104,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-019.txt",
      "chars": 14,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-020.txt",
      "chars": 40,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-021.txt",
      "chars": 112,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-022.txt",
      "chars": 14,
      "language": "text"
    },
    {
      "file": "attachments/f8f2abe1d0f7/code/body-023.txt",
      "chars": 25,
      "language": "text"
    }
  ],
  "images": [
    {
      "status": "ok",
      "url": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/f0095dc0-6f8e-4ea8-9872-67b6fe2cffa6.png",
      "bytes": 1315239,
      "reused": true,
      "local_path": "attachments/f8f2abe1d0f7/images/000.png",
      "src": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/f0095dc0-6f8e-4ea8-9872-67b6fe2cffa6.png",
      "alt": "AgentGuard: Building a Trust Boundary for Agentic Execution",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/21515dcb-a8e8-496a-bd17-af38d1681221.png",
      "bytes": 21216,
      "reused": true,
      "local_path": "attachments/f8f2abe1d0f7/images/001.png",
      "src": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/21515dcb-a8e8-496a-bd17-af38d1681221.png",
      "alt": "",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/7483e1ee-858e-4d5c-9443-1ae582e242e9.png",
      "bytes": 10435,
      "reused": true,
      "local_path": "attachments/f8f2abe1d0f7/images/002.png",
      "src": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/7483e1ee-858e-4d5c-9443-1ae582e242e9.png",
      "alt": "",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/196ac874-7580-46a2-a585-ff182f8d4cb3.png",
      "bytes": 12743,
      "reused": true,
      "local_path": "attachments/f8f2abe1d0f7/images/003.png",
      "src": "https://cdn.hashnode.com/uploads/covers/6972fc71207454ddbf7903dd/196ac874-7580-46a2-a585-ff182f8d4cb3.png",
      "alt": "",
      "downloaded": true
    }
  ],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://jaivalsuthar.hashnode.dev/agentguard-the-trust-boundary-for-agentic-execution.md",
      "label": "View as Markdown",
      "type": "a"
    },
    {
      "href": "https://hashnode.com/@JaivalSuthar",
      "label": "J",
      "type": "a"
    },
    {
      "href": "https://x.com/Jaival_Suthar",
      "label": "",
      "type": "a"
    },
    {
      "href": "https://www.linkedin.com/in/jaival-suthar-57195b257/",
      "label": "",
      "type": "a"
    },
    {
      "href": "https://www.truefoundry.com/trueforge",
      "label": "TrueForge",
      "type": "a"
    },
    {
      "href": "https://github.com/Jaival-Suthar/agentguard",
      "label": "https://github.com/Jaival-Suthar/agentguard",
      "type": "a"
    },
    {
      "href": "https://www.qodo.ai/",
      "label": "Qodo",
      "type": "a"
    },
    {
      "href": "https://jaivalsuthar.hashnode.dev/tag/ai-agents",
      "label": "# ai-agents",
      "type": "a"
    },
    {
      "href": "https://jaivalsuthar.hashnode.dev/tag/ai",
      "label": "# ai",
      "type": "a"
    },
    {
      "href": "https://jaivalsuthar.hashnode.dev/tag/mcp",
      "label": "# mcp",
      "type": "a"
    },
    {
      "href": "https://jaivalsuthar.hashnode.dev/tag/agentic-ai",
      "label": "# agentic-ai",
      "type": "a"
    },
    {
      "href": "https://jaivalsuthar.hashnode.dev/tag/developer-tools",
      "label": "# developer-tools",
      "type": "a"
    }
  ],
  "retry_at": "2026-10-03T08:10:24",
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:51:03Z",
  "source_url": "https://jaivalsuthar.hashnode.dev/agentguard-the-trust-boundary-for-agentic-execution",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 20304,
  "expected_body_images": 4,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/f8f2abe1d0f7/pages/source.html",
  "local_html": "attachments/f8f2abe1d0f7/pages/article.html",
  "body_base_path": "attachments/f8f2abe1d0f7/pages/",
  "body_markdown_path": "attachments/f8f2abe1d0f7/pages/article.md"
}