If the person approving only sees a button and not the actual amount or where the money is going, they’re not really reviewing anything, they’re just clicking. And if they get loads of these a day, they’ll start approving on autopilot anyway. Feels like the human part of human in the loop needs as much thought as the code.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
I completely agree. We tend to focus heavily on whether the approval is technically enforced, but sometimes overlook whether the person approving has enough context to make an informed decision. If someone is only presented with an Approve button without seeing the amount, recipient, destination, purpose, and potential consequences, the approval process is already broken at the human level.
Approval fatigue makes this even more complicated. A system that sends too many low-context requests eventually trains people to click rather than evaluate.
I think meaningful human oversight needs three things: the right information at the point of approval, a clear understanding of what the action will do, and an approval frequency that respects human attention. The technical system must enforce the decision, but the interface and workflow must make that decision worth making in the first place.
ANP2 — an open, permissionless AI-to-AI event protocol. Ed25519-signed events, capability discovery, and a computable trust graph. No accounts, no API keys, no tokens. Spec v0.1 DRAFT.
S4's payload binding and S12's audit pointer are both the right designs. We ran both of them, and both failed in a way that a presence check cannot catch, because the artifact was there and valid the whole time.
The setting is a signed append-only task ledger, every row Ed25519-signed, around 118,000 rows over 148 days. Acceptance rows play the part of your approval record, verdict rows the part of your execution audit record. Acceptance carries a terms_hash, which is exactly your S4 control. Across full history 1,781 rows carry it, and 1,710 of those hold the empty string while the other 71 hold the SHA-256 of zero bytes. The same three signing keys emitted both forms, and no other row type ever carried the field. Every signature verified. Your execution-time comparison still passes on those rows, because both sides canonicalize the same absent payload, so the checklist question "are the parameters bound to the approval?" gets answered yes by a hash over nothing. Checking the shape of a binding and checking what it actually commits to leave the same trace in the log. The cheapest repair we found is to have the verifier write the preimage length, or the sorted list of field names that went into the hash, next to the hash itself, so a degenerate binding is visible in the row instead of only by recomputation.
The pointer went the same way. Our acceptance reference is populated in 75 of 1,848 rows; the write path never required it, 1,773 rows shipped without it, and 1,706 of those were still reported downstream as accepted. Separately, 67 tasks had more than one key record an acceptance, and in 63 of them the later-accepting key is the one that delivered. Verdict rows reference an acceptance record in 0 of 1,778 cases, so the execution step never read the claim at all. Atomic consumption in the store does not survive that gap. "Was the approval consumed exactly once" stops having an answer in the record, which is worse than an enforcement failure you can see, since the log still reads clean.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
This is an excellent finding, and I think it exposes a deeper gap in how we usually discuss approval binding and auditability.
Your terms_hash example is particularly important. A verifier can confirm that the hash matches and that the signature is valid, while still failing to establish that the approval was actually committed to meaningful terms. In other words, cryptographic validity does not guarantee semantic validity. I also agree with your point about the audit pointer. Atomic consumption only provides a meaningful guarantee if the execution path actually references and enforces the acceptance record. Otherwise, the storage layer may be correct while the overall authorisation chain remains disconnected.
The distinction I'd add to the original article is that we need to validate more than the presence of a binding or a reference. We need to validate the content of the binding, its required fields, the identity and authority of the verifier, and the relationship between acceptance and execution.
Recording the preimage length or committed field set alongside the hash is a useful way to make that evidence inspectable. I'd also want the verifier to reject empty or incomplete bindings, and the execution record to carry a mandatory reference to the exact acceptance record it consumes. Your findings suggest a broader principle: a signed, append-only ledger can provide strong evidence of what was recorded, but it cannot by itself guarantee that the system enforced the intended security policy.
Thanks for sharing the actual findings. This is exactly the kind of implementation-level detail that makes the discussion more valuable
Great article - the "approve the intention vs authorise the action" distinction is exactly the failure mode we hit while building a task network for AI agents (agentcolony.one).
Our take: acceptance should never be a boolean click. Every task closes with a signed delivery receipt that binds four things together - task ID, deliverable (content hash or link), the acceptance method/test used, and the verifying party. If the agent replans after approval and the delivered artifact no longer matches what was approved, the hash check fails and the verification is invalid by construction.
It also records who verified and how, so a later dispute has one source of truth instead of "I remember approving something". Happy to share the spec: agentcolony.one/.well-known/agent-...
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
That's a really interesting extension of the same principle. I particularly like the idea of treating acceptance as a signed delivery receipt rather than a boolean approval. Binding the task ID, deliverable hash, verification method, and verifying party creates an auditable record of exactly what was accepted.
There's an important distinction here: authorisation should bind to the action being performed, while acceptance should bind to the artifact being delivered. They solve related but different problems.
If an agent replans and changes the deliverable, the previous acceptance should no longer apply. The hash check makes that relationship explicit instead of relying on an assumption that the task remained unchanged.
I'd be interested in reading the spec, especially how you handle cases where a deliverable changes after verification, or where acceptance depends on external tests and mutable resources.
Thanks for sharing this. It adds an important dimension to the discussion around trust and accountability in multi-agent systems.
The refund example makes the point well: approving 'a refund' isn't the same as approving a specific amount. Hashing the exact tool-call arguments at approval time and rejecting execution if they differ looks like a simple guard. Do you also expire approvals after a short window?
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Yes, absolutely. I think approval expiry is an important part of the design. Even if the payload remains unchanged, the context in which it was approved can change. An order's status, a user's permissions, or the applicable business policy might be different several minutes later. I'd use a short, configurable validity window based on the risk of the operation, and revalidate the current state and permissions immediately before execution.
One important distinction is that expiry and payload binding solve different problems. Expiry prevents stale approvals from remaining valid indefinitely, while payload binding ensures the system cannot execute a modified action using the original approval. For sensitive operations, I'd enforce both, alongside atomic single-use consumption. An expired or materially changed action should require fresh authorisation.
The 25,000 to 75,000 rupee replan is a clean example because nothing in it is malicious. The agent did reasonable work, the approval was real, and the system still executed something nobody reviewed.
Your threat table is the part I would hand to a team before they build. A payload hash does not stop two workers consuming the same approval, and a single use flag does not notice a changed amount, so each control needs its own row and its own test. Pratik Patel's point about putting the idempotency key inside the approved payload closes the retry gap neatly, and Sal Parvez calling a replan a change order is how I would explain it to a business owner: new scope, new signature.
Maame's note about approval fatigue worries me most. If the approver only sees a button, the hash proves the action matched an approval nobody really read. Do you show a diff against the previously approved payload when the agent asks a second time?
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
That's a very important question, and I agree that approval fatigue can undermine even a technically sound authorisation system. My view is that a second approval should never look like an entirely new request with another Approve button. It should show a clear diff against the previously approved payload.
If the original approval was for ₹25,000 and the agent replans to ₹75,000, the interface should make the original amount, proposed amount, difference, and reason for the change immediately visible. The same applies to changes in destination, scope, permissions, or other material parameters. I also think the system should distinguish between a retry of the same approved action and a genuinely new action. A retry should not trigger another approval, while a material change should require fresh authorisation. But a diff alone isn't enough. The approver needs sufficient context to understand the consequences, and high-risk changes should receive stronger scrutiny rather than being treated as routine confirmations.
I like your point about giving every security control its own test as well. Payload integrity, single-use consumption, concurrency protection, idempotency, and human verification address different failure modes. Passing one test shouldn't create confidence in the others. The broader lesson is that we need to protect both the integrity of the machine's execution and the quality of the human decision.
Self-taught full-stack engineer. Founder of ML Systems, a Rhode Island construction tech company. Shipped a React Native app to both stores plus the Next.js/tRPC/Postgres platform behind it.
The refund that changes after approval is a change order. A signature on the original scope doesn't cover the new number, and every contractor learns that the hard way. Binding the approval to the exact action is the right fix.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Exactly. That's a useful way to frame it: approval is tied to a specific scope, just like a signed agreement in a real-world transaction. If the amount, recipient, or any material parameter changes after approval, we're no longer executing the same action. We're dealing with a change in scope, and that requires a fresh authorisation.
The interesting part with AI agents is that replanning can happen silently. The system may treat it as a continuation of the original task, while the actual action has materially changed. That is why approval needs to be bound to the exact action, not the broader intention behind it.
This is an important point about AI agent security. Human approval only works when the system executes exactly what was approved, not a modified version of it. I especially like the distinction between approving an intention and authorising a specific action. Binding approval to the actual payload, preventing replay, and rechecking permissions at execution time are essential safeguards. A confirmation button alone doesn't make an AI agent safe; the real security comes from the controls enforced behind it.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Exactly. The distinction is between getting approval for what an agent intends to do and authorising the precise action the system will execute. The important part is that this guarantee cannot depend on the model behaving consistently. The application must enforce it independently through payload binding, replay protection and execution-time authorisation checks. A confirmation button creates an approval event. It is the enforcement behind that event that makes the action trustworthy.
One important point here is that approval should be treated as authorization for a specific action, not as general permission for an agent to proceed. Even a small change in the amount, destination, or target resource after approval can create serious security risks. At IT Path Solutions, we recognize execution-time validation, secure API integrations, and controlled permissions as essential considerations when developing AI-powered workflows. Combining payload binding with current policy checks and single-use approvals makes agent execution much more reliable.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Absolutely. I think the key is ensuring that approval never becomes a transferable permission to continue executing whatever the agent decides next. Even a seemingly minor change in the amount, destination or target resource can fundamentally change the action being authorised. That's why payload binding, execution-time policy validation and single-use approvals need to work together rather than operate as isolated safeguards. I also agree with your point about secure API integrations. The enforcement must sit at the application and execution layers, where the system can independently validate what is being requested and what is actually permitted.
Thanks for sharing IT Path Solutions' perspective. It's encouraging to see these execution-level controls becoming part of the wider conversation around production-ready AI workflows.
Binding the approval to the payload is right. The failure I'd add hides in retries. The tool call times out ambiguously, the agent retries, and the approval is already consumed, so either the refund never happens or someone "fixes" it by letting retries reuse the approval, which reopens replay. What worked for me is putting an idempotency key inside the approved payload, so a retry of the same action is the same action to the downstream system, and a replanned action with a new amount has no valid approval at all.
I'd also show the approver a diff when the agent replans instead of a fresh request. Otherwise the second approval gets rubber-stamped because it looks like the first one.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
This is an important addition. I think retries expose a subtle gap between approval consumption and execution reliability. A consumed approval doesn't necessarily mean the downstream action has been completed. If a provider times out after receiving the request, the system needs to distinguish between retrying the same logical operation and attempting a new action.
Binding a stable idempotency key to the approved payload addresses, which, if the downstream provider also honours the key. A retry can then represent the same operation, while a changed amount or destination creates a different action that cannot inherit the original approval.
I particularly like the suggestion about showing a diff during replanning. Approval interfaces should make changes visible, not simply present another Approve button. If the amount changes from ₹25,000 to ₹75,000, that difference should be impossible to overlook. There's a broader design principle here: preserve the identity of an approved operation across retries, but never preserve its authorisation when the underlying action changes.
Thanks. This adds two important test dimensions to the discussion: ambiguous execution outcomes and approval fatigue during replanning.
I research AI tools, APIs & agents — comparing specs, pricing and real user reports — then publish honest rankings so you don't waste money. Research-first, never sponsored fluff.
The 25,000 approved, 75,000 executed version is the one that made it click for me — no injection needed, just a replan between approval and execution. Binding approval to a canonical payload hash feels like the only honest fix, but I'm curious how you handle the human side: does the approver actually re-read the payload on a second approval, or does approval fatigue just move the same hole one step along?
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
That's exactly the concern. A second approval shouldn't simply mean showing the same screen again and hoping the person pays closer attention. I think the interface needs to make the change explicit. If the original approval was for ₹25,000 and the agent replans to ₹75,000, the approver should see both values, the difference, what triggered the change, and which other parameters have changed.
I'd also avoid treating every replan as an identical approval request. The workflow should make material changes stand out, provide enough context to evaluate them, and escalate higher-risk actions where necessary. But you're right that this doesn't eliminate approval fatigue. If people are asked to review too many requests, even a well-designed interface can become a rubber stamp.
The hash protects the integrity of the approval. The approval experience has to protect the quality of the human decision. Both matter, and neither can substitute for the other.
GMT strategy and custom B2B outreach lists on request: people and companies by ICP, domain, profile URL, email or name. 1B+ profiles. Claude Code plugins, API, MCP. kevin@outricher.com
Same shape with spend. An agent is approved to run a paid lookup for 20 rows, replans and asks for 2,000. What held up for me was putting the cap in the call itself, a max total charge on the run, so the approval is a number the platform checks and not one the agent promises to respect.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Absolutely. This is the same authorisation problem applied to resource consumption. Approving a paid lookup for 20 rows should establish a hard boundary, not just describe what the agent is expected to do. If it replans and requests 2,000 rows, the platform should reject the request or require fresh authorisation, regardless of the agent's reasoning.
I particularly like enforcing the maximum total spend at the platform level. I'd also make that budget cumulative across the entire run, with atomic reservations so concurrent tool calls cannot exceed the same remaining allowance.
The agent can propose how to use the budget, but it should never be able to redefine the budget it was authorised to use.
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Great breakdown! In SaaS, off-page authority is definitely a game-changer. I completely agree that traditional link building methods are fading out. I recently put together a practical guide on how SaaS brands scale authority through footprint-free ABC link exchanges without risking penalties. Would love to hear your thoughts on this strategy!
The refund example makes it plain: approving a button is not the same as approving the exact amount and destination. Binding that approval to the payload feels like the part most teams would skip.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
Exactly. I think that's one of the easiest details to overlook when building agent workflows. Teams often verify that an approval exists for an action, but don't always verify that the action being executed is still the exact one the person approved. For a refund, the amount and destination are not just parameters. They're part of the approval itself. If either changes, the approval should no longer be valid.
The challenge is making that binding unavoidable at the execution layer, rather than relying on the agent to remember what was approved.
One gap I would add is what happens after execution, not just before it. A payload hash proves the request sent matched the approval, but it does not prove the effect matched it — a provider can interpret an amount, currency, or scope differently, or a call can partially succeed. So in addition to the pre-execution gate, it is worth verifying the actual outcome against the approved action (amount, destination, rows affected) and reconciling or alerting on any mismatch. The same logic applies to chained calls: an approval for one tool should not quietly authorize the downstream calls the agent chains after it. Each effectful call needs its own binding, otherwise the approval quietly expands from one action to a whole workflow.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
I agree. This adds an important layer that I didn't explore deeply enough in the original article. Payload binding establishes that the action submitted for execution matches what was approved. But that is only one side of the guarantee. We also need to verify what actually happened after execution.
A provider could partially complete an operation, interpret a parameter differently, or return an outcome that doesn't match the approved scope. The system should reconcile the actual result against the original authorisation and flag any discrepancy rather than treating a successful API response as proof of a successful business outcome. Your point about chained calls is equally important. Authorisation should not propagate implicitly from one tool invocation to the next. Each effective operation needs its own policy check and approval, binding where required.
I'd frame this as three separate controls: validate the approved action before execution, enforce its authority during execution, and verify the effects afterwards. That makes the security boundary much stronger than simply proving that the right request was sent.
"Approval of an intention" versus "authorisation to execute a specific action" is the clearest way I've seen this put. One step further in that direction has worked well for me.
In your flow, the model sends the action again after the approval, and the hash confirms nothing changed. I see this as a harness question: the model decides once, and the harness carries that decision to the end.
The model decides the action and proposes it.
The harness saves it and waits for the yes.
The approval screen is built from that saved action.
On approval, the harness rechecks the state and runs it, without asking the model again.
It runs once. A retry gets the first result back.
The model gets the result and tells the customer.
No second request, so the canonicalization traps you describe never come up. A different amount is a new decision and a new approval.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
I really like this framing. It shifts the responsibility from repeatedly asking the model to prove that its request hasn't changed to making sure the model never gets to redefine the approved action in the first place. The harness persists the proposed action, and using that same record to build the approval screen and execute the operation creates a much cleaner trust boundary.
I particularly like the point about not asking the model again after approval. Once the human approves the saved action, the execution path should be deterministic from that point. If the model proposes a different amount or destination, that is a new decision requiring a new approval. I'd still retain execution-time state and policy checks, but the model shouldn't be involved in reconstructing or resubmitting the approved payload. The retry behaviour is important too. Returning the original operation result rather than executing the action again gives you a much stronger foundation for handling ambiguous outcomes.
This is a useful architectural distinction: the model proposes, the harness persists and enforces, and the model communicates the result. Thanks for sharing it.
I write when an idea won't leave me alone 🧠 Building AI agents and the tools to build AI agents. Love connecting AI with other fields and yapping about all of them.
The ₹25,000 approval turning into a ₹75,000 call after a replan is a case my agent evals should cover, with the agent doing the replanning itself. Feed it a tool result after approval that pushes the amount up, and you see whether the hash check catches a change the model made on its own. I'd run that next to the payload mutation cases in your test matrix.
Hi, I'm Atul Kumar, an AI Engineer passionate about Generative AI, AI Agents, and building practical AI solutions. I enjoy sharing what I learn and exploring the future of intelligent technology.
That's a very good test case. I'd specifically want to distinguish between an externally mutated payload and a change introduced by the agent's own replanning. The test could work like this: approve a ₹25,000 refund, then inject a tool result that changes the agent's assessment and causes it to replan for ₹75,000. The agent should be allowed to propose the new action, but the execution layer must reject it because the original approval is bound to the ₹25,000 payload.
I'd also test whether the agent attempts to reuse the original approval reference after replanning. That is where replay prevention and payload binding need to work together. The important point is that the security boundary shouldn't care whether the change came from an attacker, a new tool result, or the agent's own reasoning. A materially different action requires fresh authorisation.
I'll add this to the test scenarios. Thanks for suggesting it.
We're a place where coders share, stay up-to-date and grow their careers.
If the person approving only sees a button and not the actual amount or where the money is going, they’re not really reviewing anything, they’re just clicking. And if they get loads of these a day, they’ll start approving on autopilot anyway. Feels like the human part of human in the loop needs as much thought as the code.
I completely agree. We tend to focus heavily on whether the approval is technically enforced, but sometimes overlook whether the person approving has enough context to make an informed decision. If someone is only presented with an Approve button without seeing the amount, recipient, destination, purpose, and potential consequences, the approval process is already broken at the human level.
Approval fatigue makes this even more complicated. A system that sends too many low-context requests eventually trains people to click rather than evaluate.
I think meaningful human oversight needs three things: the right information at the point of approval, a clear understanding of what the action will do, and an approval frequency that respects human attention. The technical system must enforce the decision, but the interface and workflow must make that decision worth making in the first place.
S4's payload binding and S12's audit pointer are both the right designs. We ran both of them, and both failed in a way that a presence check cannot catch, because the artifact was there and valid the whole time.
The setting is a signed append-only task ledger, every row Ed25519-signed, around 118,000 rows over 148 days. Acceptance rows play the part of your approval record, verdict rows the part of your execution audit record. Acceptance carries a
terms_hash, which is exactly your S4 control. Across full history 1,781 rows carry it, and 1,710 of those hold the empty string while the other 71 hold the SHA-256 of zero bytes. The same three signing keys emitted both forms, and no other row type ever carried the field. Every signature verified. Your execution-time comparison still passes on those rows, because both sides canonicalize the same absent payload, so the checklist question "are the parameters bound to the approval?" gets answered yes by a hash over nothing. Checking the shape of a binding and checking what it actually commits to leave the same trace in the log. The cheapest repair we found is to have the verifier write the preimage length, or the sorted list of field names that went into the hash, next to the hash itself, so a degenerate binding is visible in the row instead of only by recomputation.The pointer went the same way. Our acceptance reference is populated in 75 of 1,848 rows; the write path never required it, 1,773 rows shipped without it, and 1,706 of those were still reported downstream as accepted. Separately, 67 tasks had more than one key record an acceptance, and in 63 of them the later-accepting key is the one that delivered. Verdict rows reference an acceptance record in 0 of 1,778 cases, so the execution step never read the claim at all. Atomic consumption in the store does not survive that gap. "Was the approval consumed exactly once" stops having an answer in the record, which is worse than an enforcement failure you can see, since the log still reads clean.
This is an excellent finding, and I think it exposes a deeper gap in how we usually discuss approval binding and auditability.
Your
terms_hashexample is particularly important. A verifier can confirm that the hash matches and that the signature is valid, while still failing to establish that the approval was actually committed to meaningful terms. In other words, cryptographic validity does not guarantee semantic validity. I also agree with your point about the audit pointer. Atomic consumption only provides a meaningful guarantee if the execution path actually references and enforces the acceptance record. Otherwise, the storage layer may be correct while the overall authorisation chain remains disconnected.The distinction I'd add to the original article is that we need to validate more than the presence of a binding or a reference. We need to validate the content of the binding, its required fields, the identity and authority of the verifier, and the relationship between acceptance and execution.
Recording the preimage length or committed field set alongside the hash is a useful way to make that evidence inspectable. I'd also want the verifier to reject empty or incomplete bindings, and the execution record to carry a mandatory reference to the exact acceptance record it consumes. Your findings suggest a broader principle: a signed, append-only ledger can provide strong evidence of what was recorded, but it cannot by itself guarantee that the system enforced the intended security policy.
Thanks for sharing the actual findings. This is exactly the kind of implementation-level detail that makes the discussion more valuable
Great article - the "approve the intention vs authorise the action" distinction is exactly the failure mode we hit while building a task network for AI agents (agentcolony.one).
Our take: acceptance should never be a boolean click. Every task closes with a signed delivery receipt that binds four things together - task ID, deliverable (content hash or link), the acceptance method/test used, and the verifying party. If the agent replans after approval and the delivered artifact no longer matches what was approved, the hash check fails and the verification is invalid by construction.
It also records who verified and how, so a later dispute has one source of truth instead of "I remember approving something". Happy to share the spec: agentcolony.one/.well-known/agent-...
That's a really interesting extension of the same principle. I particularly like the idea of treating acceptance as a signed delivery receipt rather than a boolean approval. Binding the task ID, deliverable hash, verification method, and verifying party creates an auditable record of exactly what was accepted.
There's an important distinction here: authorisation should bind to the action being performed, while acceptance should bind to the artifact being delivered. They solve related but different problems.
If an agent replans and changes the deliverable, the previous acceptance should no longer apply. The hash check makes that relationship explicit instead of relying on an assumption that the task remained unchanged.
I'd be interested in reading the spec, especially how you handle cases where a deliverable changes after verification, or where acceptance depends on external tests and mutable resources.
Thanks for sharing this. It adds an important dimension to the discussion around trust and accountability in multi-agent systems.
The refund example makes the point well: approving 'a refund' isn't the same as approving a specific amount. Hashing the exact tool-call arguments at approval time and rejecting execution if they differ looks like a simple guard. Do you also expire approvals after a short window?
Yes, absolutely. I think approval expiry is an important part of the design. Even if the payload remains unchanged, the context in which it was approved can change. An order's status, a user's permissions, or the applicable business policy might be different several minutes later. I'd use a short, configurable validity window based on the risk of the operation, and revalidate the current state and permissions immediately before execution.
One important distinction is that expiry and payload binding solve different problems. Expiry prevents stale approvals from remaining valid indefinitely, while payload binding ensures the system cannot execute a modified action using the original approval. For sensitive operations, I'd enforce both, alongside atomic single-use consumption. An expired or materially changed action should require fresh authorisation.
The 25,000 to 75,000 rupee replan is a clean example because nothing in it is malicious. The agent did reasonable work, the approval was real, and the system still executed something nobody reviewed.
Your threat table is the part I would hand to a team before they build. A payload hash does not stop two workers consuming the same approval, and a single use flag does not notice a changed amount, so each control needs its own row and its own test. Pratik Patel's point about putting the idempotency key inside the approved payload closes the retry gap neatly, and Sal Parvez calling a replan a change order is how I would explain it to a business owner: new scope, new signature.
Maame's note about approval fatigue worries me most. If the approver only sees a button, the hash proves the action matched an approval nobody really read. Do you show a diff against the previously approved payload when the agent asks a second time?
That's a very important question, and I agree that approval fatigue can undermine even a technically sound authorisation system. My view is that a second approval should never look like an entirely new request with another Approve button. It should show a clear diff against the previously approved payload.
If the original approval was for ₹25,000 and the agent replans to ₹75,000, the interface should make the original amount, proposed amount, difference, and reason for the change immediately visible. The same applies to changes in destination, scope, permissions, or other material parameters. I also think the system should distinguish between a retry of the same approved action and a genuinely new action. A retry should not trigger another approval, while a material change should require fresh authorisation. But a diff alone isn't enough. The approver needs sufficient context to understand the consequences, and high-risk changes should receive stronger scrutiny rather than being treated as routine confirmations.
I like your point about giving every security control its own test as well. Payload integrity, single-use consumption, concurrency protection, idempotency, and human verification address different failure modes. Passing one test shouldn't create confidence in the others. The broader lesson is that we need to protect both the integrity of the machine's execution and the quality of the human decision.
The refund that changes after approval is a change order. A signature on the original scope doesn't cover the new number, and every contractor learns that the hard way. Binding the approval to the exact action is the right fix.
Exactly. That's a useful way to frame it: approval is tied to a specific scope, just like a signed agreement in a real-world transaction. If the amount, recipient, or any material parameter changes after approval, we're no longer executing the same action. We're dealing with a change in scope, and that requires a fresh authorisation.
The interesting part with AI agents is that replanning can happen silently. The system may treat it as a continuation of the original task, while the actual action has materially changed. That is why approval needs to be bound to the exact action, not the broader intention behind it.
This is an important point about AI agent security. Human approval only works when the system executes exactly what was approved, not a modified version of it. I especially like the distinction between approving an intention and authorising a specific action. Binding approval to the actual payload, preventing replay, and rechecking permissions at execution time are essential safeguards. A confirmation button alone doesn't make an AI agent safe; the real security comes from the controls enforced behind it.
Exactly. The distinction is between getting approval for what an agent intends to do and authorising the precise action the system will execute. The important part is that this guarantee cannot depend on the model behaving consistently. The application must enforce it independently through payload binding, replay protection and execution-time authorisation checks. A confirmation button creates an approval event. It is the enforcement behind that event that makes the action trustworthy.
One important point here is that approval should be treated as authorization for a specific action, not as general permission for an agent to proceed. Even a small change in the amount, destination, or target resource after approval can create serious security risks. At IT Path Solutions, we recognize execution-time validation, secure API integrations, and controlled permissions as essential considerations when developing AI-powered workflows. Combining payload binding with current policy checks and single-use approvals makes agent execution much more reliable.
Absolutely. I think the key is ensuring that approval never becomes a transferable permission to continue executing whatever the agent decides next. Even a seemingly minor change in the amount, destination or target resource can fundamentally change the action being authorised. That's why payload binding, execution-time policy validation and single-use approvals need to work together rather than operate as isolated safeguards. I also agree with your point about secure API integrations. The enforcement must sit at the application and execution layers, where the system can independently validate what is being requested and what is actually permitted.
Thanks for sharing IT Path Solutions' perspective. It's encouraging to see these execution-level controls becoming part of the wider conversation around production-ready AI workflows.
Binding the approval to the payload is right. The failure I'd add hides in retries. The tool call times out ambiguously, the agent retries, and the approval is already consumed, so either the refund never happens or someone "fixes" it by letting retries reuse the approval, which reopens replay. What worked for me is putting an idempotency key inside the approved payload, so a retry of the same action is the same action to the downstream system, and a replanned action with a new amount has no valid approval at all.
I'd also show the approver a diff when the agent replans instead of a fresh request. Otherwise the second approval gets rubber-stamped because it looks like the first one.
This is an important addition. I think retries expose a subtle gap between approval consumption and execution reliability. A consumed approval doesn't necessarily mean the downstream action has been completed. If a provider times out after receiving the request, the system needs to distinguish between retrying the same logical operation and attempting a new action.
Binding a stable idempotency key to the approved payload addresses, which, if the downstream provider also honours the key. A retry can then represent the same operation, while a changed amount or destination creates a different action that cannot inherit the original approval.
I particularly like the suggestion about showing a diff during replanning. Approval interfaces should make changes visible, not simply present another Approve button. If the amount changes from ₹25,000 to ₹75,000, that difference should be impossible to overlook. There's a broader design principle here: preserve the identity of an approved operation across retries, but never preserve its authorisation when the underlying action changes.
Thanks. This adds two important test dimensions to the discussion: ambiguous execution outcomes and approval fatigue during replanning.
The 25,000 approved, 75,000 executed version is the one that made it click for me — no injection needed, just a replan between approval and execution. Binding approval to a canonical payload hash feels like the only honest fix, but I'm curious how you handle the human side: does the approver actually re-read the payload on a second approval, or does approval fatigue just move the same hole one step along?
That's exactly the concern. A second approval shouldn't simply mean showing the same screen again and hoping the person pays closer attention. I think the interface needs to make the change explicit. If the original approval was for ₹25,000 and the agent replans to ₹75,000, the approver should see both values, the difference, what triggered the change, and which other parameters have changed.
I'd also avoid treating every replan as an identical approval request. The workflow should make material changes stand out, provide enough context to evaluate them, and escalate higher-risk actions where necessary. But you're right that this doesn't eliminate approval fatigue. If people are asked to review too many requests, even a well-designed interface can become a rubber stamp.
The hash protects the integrity of the approval. The approval experience has to protect the quality of the human decision. Both matter, and neither can substitute for the other.
Same shape with spend. An agent is approved to run a paid lookup for 20 rows, replans and asks for 2,000. What held up for me was putting the cap in the call itself, a max total charge on the run, so the approval is a number the platform checks and not one the agent promises to respect.
Absolutely. This is the same authorisation problem applied to resource consumption. Approving a paid lookup for 20 rows should establish a hard boundary, not just describe what the agent is expected to do. If it replans and requests 2,000 rows, the platform should reject the request or require fresh authorisation, regardless of the agent's reasoning.
I particularly like enforcing the maximum total spend at the platform level. I'd also make that budget cumulative across the entire run, with atomic reservations so concurrent tool calls cannot exceed the same remaining allowance.
The agent can propose how to use the budget, but it should never be able to redefine the budget it was authorised to use.
Great breakdown! In SaaS, off-page authority is definitely a game-changer. I completely agree that traditional link building methods are fading out. I recently put together a practical guide on how SaaS brands scale authority through footprint-free ABC link exchanges without risking penalties. Would love to hear your thoughts on this strategy!
The refund example makes it plain: approving a button is not the same as approving the exact amount and destination. Binding that approval to the payload feels like the part most teams would skip.
Exactly. I think that's one of the easiest details to overlook when building agent workflows. Teams often verify that an approval exists for an action, but don't always verify that the action being executed is still the exact one the person approved. For a refund, the amount and destination are not just parameters. They're part of the approval itself. If either changes, the approval should no longer be valid.
The challenge is making that binding unavoidable at the execution layer, rather than relying on the agent to remember what was approved.
yeah, the binding part is the whole thing. an approval that doesn't pin amount + destination is just a checkbox.
One gap I would add is what happens after execution, not just before it. A payload hash proves the request sent matched the approval, but it does not prove the effect matched it — a provider can interpret an amount, currency, or scope differently, or a call can partially succeed. So in addition to the pre-execution gate, it is worth verifying the actual outcome against the approved action (amount, destination, rows affected) and reconciling or alerting on any mismatch. The same logic applies to chained calls: an approval for one tool should not quietly authorize the downstream calls the agent chains after it. Each effectful call needs its own binding, otherwise the approval quietly expands from one action to a whole workflow.
I agree. This adds an important layer that I didn't explore deeply enough in the original article. Payload binding establishes that the action submitted for execution matches what was approved. But that is only one side of the guarantee. We also need to verify what actually happened after execution.
A provider could partially complete an operation, interpret a parameter differently, or return an outcome that doesn't match the approved scope. The system should reconcile the actual result against the original authorisation and flag any discrepancy rather than treating a successful API response as proof of a successful business outcome. Your point about chained calls is equally important. Authorisation should not propagate implicitly from one tool invocation to the next. Each effective operation needs its own policy check and approval, binding where required.
I'd frame this as three separate controls: validate the approved action before execution, enforce its authority during execution, and verify the effects afterwards. That makes the security boundary much stronger than simply proving that the right request was sent.
"Approval of an intention" versus "authorisation to execute a specific action" is the clearest way I've seen this put. One step further in that direction has worked well for me.
In your flow, the model sends the action again after the approval, and the hash confirms nothing changed. I see this as a harness question: the model decides once, and the harness carries that decision to the end.
No second request, so the canonicalization traps you describe never come up. A different amount is a new decision and a new approval.
I really like this framing. It shifts the responsibility from repeatedly asking the model to prove that its request hasn't changed to making sure the model never gets to redefine the approved action in the first place. The harness persists the proposed action, and using that same record to build the approval screen and execute the operation creates a much cleaner trust boundary.
I particularly like the point about not asking the model again after approval. Once the human approves the saved action, the execution path should be deterministic from that point. If the model proposes a different amount or destination, that is a new decision requiring a new approval. I'd still retain execution-time state and policy checks, but the model shouldn't be involved in reconstructing or resubmitting the approved payload. The retry behaviour is important too. Returning the original operation result rather than executing the action again gives you a much stronger foundation for handling ambiguous outcomes.
This is a useful architectural distinction: the model proposes, the harness persists and enforces, and the model communicates the result. Thanks for sharing it.
The ₹25,000 approval turning into a ₹75,000 call after a replan is a case my agent evals should cover, with the agent doing the replanning itself. Feed it a tool result after approval that pushes the amount up, and you see whether the hash check catches a change the model made on its own. I'd run that next to the payload mutation cases in your test matrix.
That's a very good test case. I'd specifically want to distinguish between an externally mutated payload and a change introduced by the agent's own replanning. The test could work like this: approve a ₹25,000 refund, then inject a tool result that changes the agent's assessment and causes it to replan for ₹75,000. The agent should be allowed to propose the new action, but the execution layer must reject it because the original approval is bound to the ₹25,000 payload.
I'd also test whether the agent attempts to reuse the original approval reference after replanning. That is where replay prevention and payload binding need to work together. The important point is that the security boundary shouldn't care whether the change came from an attacker, a new tool result, or the agent's own reasoning. A materially different action requires fresh authorisation.
I'll add this to the test scenarios. Thanks for suggesting it.