A grant table is the internal MySQL record of who can do what. It stores effective privilege state inside the database, which means administrators must update and verify it carefully when granting or revoking access, especially in estates with many users and hosts.
Expanded Definition
A grant table is the database-level privilege map MySQL uses to determine who can do what, where, and against which objects. It is not just a convenience layer over access control, but the source of effective privilege state that the server consults when evaluating account permissions, host scoping, and object-level grants.
In NHI and IAM terms, a grant table matters because database access often belongs to service accounts, deployment pipelines, application runtimes, and automation agents, not just people. That makes the grant table part of the operational control plane for NIST Cybersecurity Framework 2.0 style access governance, especially when privileges are delegated across many hosts or replicated environments. MySQL-specific guidance around grant tables is operational, while broader identity governance guidance from Ultimate Guide to NHIs frames the risk: excessive privileges, weak visibility, and poor offboarding all become harder to correct once they are embedded in database records.
Usage in the industry is straightforward, but the governance implications are often underestimated because the grant table looks like administrative metadata rather than a security enforcement mechanism. The most common misapplication is treating privilege changes as complete after issuing a SQL command, which occurs when administrators fail to verify the resulting effective access across hosts and replication targets.
Examples and Use Cases
Implementing grant table management rigorously often introduces operational overhead, requiring organisations to weigh fast access changes against the cost of verification, auditing, and rollback control.
- A database administrator revokes a compromised service account, then checks the grant table to confirm the account no longer has object-level access on any host.
- A platform team provisions a new application agent and uses least-privilege grants instead of broad administrative access, aligning with database access governance patterns described in the Ultimate Guide to NHIs.
- A compliance reviewer compares actual stored privileges against expected role assignments to detect drift after emergency maintenance or manual fixes.
- A replicated MySQL estate is audited to ensure grant changes propagated correctly, since inconsistent grant tables can produce hidden access differences between nodes.
- An incident responder uses the grant table as evidence to identify which accounts could read or modify sensitive schemas during a suspected credential compromise.
For standards-based access governance, teams often pair this with NIST Cybersecurity Framework 2.0 access review practices and periodic entitlement validation. The exact implementation details vary by MySQL version and operational model, so no single standard governs this yet.
Why It Matters in NHI Security
Grant table hygiene becomes critical when non-human identities are allowed to accumulate broad database rights over time. In NHI environments, the problem is rarely one initial mistake alone. It is privilege drift, stale accounts, and missing revocation discipline. NHI Mgmt Group reports that Ultimate Guide to NHIs finds 97% of NHIs carry excessive privileges, which is exactly the kind of condition that turns a database grant table into an attack amplifier rather than a control.
When grant tables are not reviewed carefully, attackers can inherit broad rights through service accounts, orphaned application users, or mis-scoped host entries. That can expose customer records, internal telemetry, or automation credentials without triggering obvious authentication failures. The security impact is not limited to confidentiality. Overprivileged database identities can alter rows, disable logging, or tamper with application state, which complicates forensics and recovery.
Organisations typically encounter grant table risk only after a service account abuse event, at which point privilege cleanup and entitlement reconstruction become 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 address the attack and risk surface, while NIST CSF 2.0 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-02 | Grant tables store effective privileges for service accounts and other NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and validated to limit effective database rights. |
| NIST SP 800-63 | Supports identity assurance thinking, though grant tables are an authorization artifact. |
Use assured identity lifecycle controls before issuing or revoking database privileges.
