The property that the security decision, validation result, and executed payload all refer to the same transaction. Without request integrity, an application can appear to enforce safe behaviour while a later stage silently changes what actually runs.
Expanded Definition
Request integrity is the assurance that a security control, a validation result, and the executed action all bind to the same request object from start to finish. In NHI and agentic AI systems, that matters because an API call, token exchange, or tool invocation may be inspected by one control and then altered by another stage before execution. The term is used most precisely when the system preserves the transaction identity, the payload content, and the authorisation context across hops, queues, retries, and delegated execution.
Definitions vary across vendors when request integrity is discussed alongside signing, attestation, or non-repudiation, but no single standard governs this yet. For practical governance, it is closest to end-to-end binding: the thing approved is the thing executed. This is especially important when an AI agent requests tools through NIST Cybersecurity Framework 2.0 aligned controls, or when service-to-service interactions are mediated through signed claims and policy enforcement. The most common misapplication is assuming that authenticated transport alone guarantees request integrity, which occurs when intermediaries can rewrite parameters, swap destinations, or replay stale approvals after the original check has passed.
Examples and Use Cases
Implementing request integrity rigorously often introduces extra signing, verification, and correlation overhead, requiring organisations to weigh stronger tamper resistance against added latency and operational complexity.
- An AI agent requests a data export, but the tool runner must verify that the exported dataset, destination, and approval token match the original request before execution.
- A service account submits a signed API call, and the receiving service checks that retries, headers, and payload hash still correspond to the same transaction.
- A workflow engine queues a privileged action, and the downstream worker rejects any message whose claimed intent no longer matches the validated approval record.
- Secrets are injected into a pipeline step, but the integrity check ensures that the secret use case has not been swapped after policy review.
- For broader NHI risk context, Ultimate Guide to NHIs highlights how widespread secret exposure and privilege sprawl make transaction binding harder to trust in real environments.
Why It Matters in NHI Security
Request integrity is a control for preventing approved actions from becoming unapproved outcomes. When service accounts, API keys, or AI agents can be redirected mid-flight, security teams may see a valid authentication trail while the actual execution target or payload has changed. That gap undermines policy enforcement, incident response, and audit confidence. It also matters because NHIs are frequently overexposed: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, creating conditions where request tampering can turn a small control failure into broad misuse.
In governance terms, request integrity complements NIST Cybersecurity Framework 2.0 principles by ensuring that validation is not detached from execution. It is especially relevant in pipelines that involve delegation, asynchronous queues, or agentic tool calls, where the risk is not just impersonation but mismatch between what was approved and what actually ran. Organisations typically encounter this risk only after a suspicious action is traced back to a seemingly valid request, at which point request integrity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Request tampering and binding failures fit NHI request integrity and trust boundaries. |
| OWASP Agentic AI Top 10 | A-04 | Agent tool calls can diverge from approved intent if request integrity is weak. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access controls must stay aligned to the request being executed. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous enforcement of policy on each request path. |
| NIST AI RMF | AI risk management needs traceable alignment between approved and executed actions. |
Verify agent tool invocations against original intent, context, and policy before execution.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
