A dangerous parameter is the specific value, destination, object, or scope that turns an otherwise ordinary action into a high-risk one. In autonomous approval systems, security depends on whether the human explicitly named that parameter, because task-level agreement is not the same as authorising the risky detail.
Expanded Definition
A dangerous parameter is the exact value, destination, object, or scope that changes a routine action into a high-risk one. In autonomous approval systems, the key question is not whether a human approved the task generally, but whether the human explicitly authorised the risky detail that makes the action dangerous. This matters most when agents, scripts, or workflow automation can act on behalf of a person with broad execution authority.
Usage in the industry is still evolving, but the concept is closely related to contextual authorisation and scoped delegation. A safe approval can become unsafe if the parameter is substituted after approval, inferred from surrounding context, or carried forward from a previous request. For governance teams, the practical issue is whether the system binds approval to the specific parameter set, not just to the intent of the request. That distinction is central in NHI and agentic AI controls because tool access, secrets usage, and target selection can each convert a low-risk command into a sensitive action. The most common misapplication is treating task approval as parameter approval, which occurs when systems allow an agent to reuse a broad human consent for a later high-impact destination or object.
Examples and Use Cases
Implementing dangerous-parameter controls rigorously often introduces friction, requiring organisations to balance automation speed against stronger confirmation and logging.
- An AI agent can open a ticket, but deleting a production object requires the human to name the exact resource.
- A deployment workflow can run automatically, but changing the target cluster must be explicitly confirmed at approval time.
- A service account can read logs, but exporting them to an external destination becomes dangerous when the destination parameter is not separately authorised.
- A secrets rotation job can proceed, but the vault path or tenant scope must be locked to the approved value.
- A data-retrieval agent can query an internal system, but a broad search scope becomes dangerous if it expands beyond the intended project or customer set.
For background on the governance stakes around non-human identities, Ultimate Guide to NHIs shows why over-permissioned automation creates lasting exposure, while the NIST Cybersecurity Framework 2.0 helps organisations anchor the control discussion in risk-managed access and response practices.
Why It Matters in NHI Security
Dangerous parameters are where authorisation failures become concrete security incidents. NHI environments often have identity credentials, API keys, and service accounts that can execute actions faster and more broadly than a human operator. If the system cannot distinguish between approved intent and approved parameter values, an agent may perform a destructive or exfiltrating action while still appearing to follow instructions. This is why parameter binding, scope restriction, and step-up confirmation are core governance concerns, not usability extras.
The risk is amplified by the scale and weakness of non-human identity hygiene. NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, and that only 5.7% of organisations have full visibility into their service accounts. Those conditions make it easy for a dangerous parameter to pass unnoticed through logs, code, or automation pipelines. Organisations typically encounter the consequence only after a privileged action has already run with the wrong destination, object, or scope, at which point dangerous parameter review 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 Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | JSON null | Agentic systems must bind tool actions to explicitly approved parameters. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Parameter misuse often leverages over-privileged NHIs and unchecked action scope. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on limiting what parameters can be acted on. |
Constrain NHI permissions so dangerous parameters cannot expand access beyond approved bounds.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
