A specification is the expected description of what a system, feature, or control should do. It can be written as a document, diagram, backlog item, or machine-readable rule. In practice, specifications provide the baseline that development and security teams use to judge whether implementation still matches intent.
Expanded Definition
A specification is the authoritative description of intended behaviour, constraints, and acceptance criteria for a system, feature, or control. In NHI security, specifications often define how service accounts, API keys, secrets rotation, access boundaries, and agent tool permissions are expected to work, whether the artifact lives in documentation, code, infrastructure-as-code, or policy-as-code. The key distinction is that a specification describes intent, while implementation is the realised system that should conform to it. That distinction matters because security teams, developers, and auditors often compare running behaviour against a spec to detect drift, missing controls, or unsafe shortcuts.
Definitions vary across vendors when a specification is treated as a design document, a backlog item, or an executable rule set. NHI Management Group treats the term broadly because mature control environments usually span all three forms. For baseline governance, NIST Cybersecurity Framework 2.0 is useful for translating high-level outcomes into control expectations, while the Ultimate Guide to NHIs provides the identity-specific context that specifications must protect. The most common misapplication is treating a specification as proof of security, which occurs when teams equate written intent with verified enforcement in production.
Examples and Use Cases
Implementing specifications rigorously often introduces process overhead, requiring organisations to weigh consistency and auditability against delivery speed and maintenance cost.
- A platform team writes a machine-readable specification requiring every API key to rotate within a fixed window, then blocks deployment when a key exceeds that limit.
- A security team defines a service account specification that restricts tool access to one database and one queue, reducing privilege creep in agentic workflows.
- An engineering backlog item specifies that secrets must never be stored in source code, supporting review against Ultimate Guide to NHIs guidance on secrets exposure.
- A compliance control maps a specification to NIST Cybersecurity Framework 2.0 outcomes so auditors can test whether actual permissions match approved intent.
- An AI operations team specifies which tools an agent may invoke, then reviews logs to confirm the agent stayed inside those bounds during production tasks.
In practice, specifications are most valuable when they are testable, versioned, and tied to measurable controls rather than written as aspirational policy language alone.
Why It Matters in NHI Security
Specifications matter because NHI risk often emerges when the intended control and the deployed control diverge. In identity environments, that divergence can create overbroad access, stale secrets, unreviewed agent permissions, or inconsistent rotation behaviour across systems. NHI Management Group research shows that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which makes clear specification discipline essential for detecting drift before it becomes exposure. The same body of research also shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, underscoring the operational cost of vague or unenforced requirements.
Specifications also support Zero Trust and governance programs by giving teams a concrete reference for what “good” should look like before they automate controls or approve exceptions. Without that reference, access reviews, rotation schedules, and offboarding rules become inconsistent and difficult to verify. Organisations typically encounter the true cost of weak specifications only after a secret leak, privilege abuse, or failed audit, at which point the specification 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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Specifications define expected NHI behaviour and control boundaries before deployment. |
| NIST CSF 2.0 | GV.PO-01 | Policy and governance outcomes depend on clear, versioned control specifications. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, enforceable specifications for every access decision. | |
| NIST SP 800-63 | AAL2 | Identity assurance levels are specification-like requirements for authenticators and proofing. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agent tool use must be constrained by explicit behavioral specifications. |
Specify allowed tools, scopes, and escalation paths for agents, then enforce them in runtime controls.
Related resources from NHI Mgmt Group
- How can security teams tell whether a specification is secure enough to implement?
- What breaks when API security programs rely on manual specification creation?
- How do security teams know whether API specification generation is actually improving coverage?
- How should organisations use API specification exports for compliance and operational control?
