Shaping

Expanded Definition

Shaping is the deliberate work of turning a broad NHI or agentic AI problem into a reviewable direction. In practice, it means testing assumptions about identity scope, secret handling, privilege boundaries, runtime context, and operational ownership before implementation starts. In NHI security, shaping is not a design sign-off alone; it is the point where teams decide what the system must do, what it must never do, and which controls will govern it. That matters because the difference between a safe service account pattern and an unsafe one often appears long before deployment, during the framing of the use case. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to identify, protect, and govern assets from the start, not after exposure. Definitions vary across vendors when shaping is discussed in product or project terms, but the NHI security interpretation is broader: it is the stage where identity consequences are made visible before they become production risk. The most common misapplication is treating shaping as a requirements workshop, which occurs when teams skip identity-specific threat review and move straight to build decisions.

Examples and Use Cases

Implementing shaping rigorously often introduces schedule overhead, requiring organisations to weigh faster delivery against the cost of uncovering identity and access flaws too late.

• A platform team shapes a new API integration by deciding whether the workload needs a long-lived service account, a federated identity, or short-lived credentials tied to a workload identity policy.
• An agentic AI project uses shaping to define which tools the agent may call, what approvals are required, and how secrets are injected or excluded at runtime.
• A security review shapes a CI/CD automation flow by checking whether credentials are embedded in pipeline variables, externalised in a manager, or issued just in time.
• An architecture group shapes third-party access by comparing direct partner credentials with federated trust and limited-scoped delegation.
• A governance team shapes an offboarding process by clarifying when keys are revoked, who owns rotation, and how dormant NHIs are detected across environments, informed by the Ultimate Guide to NHIs and identity lifecycle guidance in the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Shaping matters because most NHI failures are not purely technical; they are the result of unclear assumptions becoming permissions, secrets, and trust relationships in production. NHI Management Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which is exactly the kind of outcome shaping is meant to prevent. When the shaping stage is weak, teams tend to over-provision access, under-specify ownership, and overlook how an agent or service account will behave under failure, retries, or compromise. That creates hidden exposure across secret sprawl, lateral movement, and poor revocation paths. It also makes later governance expensive because controls must be retrofitted onto systems that were never framed for least privilege or bounded execution. The operational lesson is that shaping is where identity risk becomes explicit enough to challenge before it hardens into architecture. Organisations typically encounter the true cost only after a breach review or access incident, at which point shaping becomes operationally unavoidable to address.