A trusted extension set is the approved collection of database extensions allowed to run in production. It narrows the amount of third-party code that can execute inside the database and reduces the chance that flexible functionality becomes an unreviewed privilege or supply chain risk.
Expanded Definition
A trusted extension set is the preapproved list of database extensions permitted in production, usually enforced by platform policy rather than by individual developers. It matters because extensions run inside the database process or with elevated database adjacency, so each added package expands the executable attack surface, the maintenance burden, and the review boundary for change control.
In NHI and agentic system designs, the term is narrower than “all approved software.” It specifically concerns third-party or built-in extension modules that can alter query behaviour, add scripting runtimes, expose file or network access, or introduce new privileged functions. In practice, the trusted set should be tied to dependency inventory, version pinning, and emergency revocation procedures, with clear ownership for review and retirement. That governance model aligns with the NIST Cybersecurity Framework 2.0 emphasis on controlled asset and configuration management, and with the broader NHI governance approach in the Ultimate Guide to NHIs.
Definitions vary across vendors on whether language extensions, procedural modules, and user-defined functions all belong in the same control set, so policy should state the exact inclusion criteria. The most common misapplication is treating any extension enabled by default as trusted, which occurs when production approval is inferred from installation availability rather than explicit security review.
Examples and Use Cases
Implementing a trusted extension set rigorously often introduces deployment friction, requiring organisations to balance database flexibility against tighter review, patching, and rollback discipline.
- An analytics platform allows only a small set of vetted extensions for time-series queries, while blocking experimental packages until security and data owners sign off.
- A payments database permits cryptographic or auditing extensions only after the Ultimate Guide to NHIs style inventory confirms ownership, version, and expiry.
- A platform team removes an unused geospatial extension after reviewing NIST Cybersecurity Framework 2.0 guidance on configuration change control and least functionality.
- An agentic application is denied direct access to install database extensions, even if it has deployment credentials for surrounding services.
- During a migration, a temporary extension is granted time-bound approval and then revoked once the application no longer depends on it.
These use cases show that the trusted set is not just a catalog item. It is an operational control that limits what code can execute inside the database boundary and defines who may approve expansion of that boundary.
Why It Matters in NHI Security
Database extensions can become a hidden privilege path for service accounts, automation pipelines, and AI agents that already hold legitimate connectivity to the data tier. If the trusted extension set is too broad, an attacker who compromises an NHI may inherit code execution opportunities that bypass application-layer controls and complicate incident containment. This is especially important because NHI exposure is already pervasive: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
A disciplined trusted extension set reduces supply chain risk by making each executable addition visible, reviewable, and removable. It also supports separation of duties, because platform operators can enforce a narrow runtime allowance even when developers request broader functionality. In security reviews, this term often surfaces alongside patch management, secret governance, and database hardening, since extension misuse frequently depends on weak change control rather than a single vulnerable package.
Organisations typically encounter the operational importance of a trusted extension set only after a compromised service account, failed audit, or hostile plugin installation makes database-side code execution an incident response problem.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and dependency governance that limits risky runtime access paths. |
| NIST CSF 2.0 | CM-2 | Configuration baselines govern which software components are permitted in production. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust limits what code and identities may execute or access a protected resource. |
Keep database extensions on a reviewed allowlist and remove any package that lacks owner, version, or expiry control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
