A function-and-trust matrix is a control model that combines an agent’s business role with an operator-assigned trust tier. The matrix determines what the agent can see, do, and hand off, making governance enforceable across live workflows rather than only in policy documents.
Expanded Definition
A function-and-trust matrix is a governance control that assigns an AI agent or other autonomous software entity two things at once: a functional scope and a trust tier. The functional scope describes the work the agent is allowed to perform, while the trust tier reflects the operator’s confidence in how much autonomy, access, or escalation authority that agent should receive. In practice, this means the matrix is not just a policy statement. It is an operational decision model that shapes runtime behavior across tools, data sources, approvals, and handoffs.
Usage in the industry is still evolving, and no single standard governs this yet. NHI Management Group treats the term as part of a broader identity and agent governance pattern, especially where agentic AI interacts with secrets, privileged actions, or sensitive workflows. The idea aligns with the control logic seen in NIST Cybersecurity Framework 2.0, even though the framework does not name this matrix directly. The key distinction is that a function-and-trust matrix governs both purpose and confidence together, rather than relying on role alone.
The most common misapplication is treating the matrix as a static chart that is never re-evaluated, which occurs when teams assign broad agent permissions once and then allow workflow changes, tool sprawl, or model drift to go unchecked.
Examples and Use Cases
Implementing a function-and-trust matrix rigorously often introduces review overhead, requiring organisations to balance faster automation against tighter control over agent actions and handoffs.
- An HR assistant agent may be permitted to draft employee onboarding tasks, but only a higher-trust tier can submit final system access requests to downstream IAM tools.
- A procurement agent might read supplier records and compare pricing, while a separate trust tier is required before it can approve purchase order creation or expose payment details.
- A security operations agent can triage alerts, but only a higher-trust profile is allowed to isolate endpoints or trigger containment through Zero Trust Architecture guidance-aligned controls.
- A customer support agent may retrieve case history, but handoff rules can prevent it from seeing full identity verification data unless a trusted operator or verified workflow escalates access.
- A code-generation agent can propose changes in a sandbox, while production deployment remains blocked until the trust tier is increased and review is completed under a governed change process.
These examples show that the matrix is most useful when different tasks need different levels of authority, even inside the same workflow. It is especially relevant where an agent touches secrets, performs privileged operations, or passes work to another system that enforces its own policy boundary.
Why It Matters for Security Teams
Security teams need a function-and-trust matrix because agentic workflows fail in predictable ways when authority is too broad, too vague, or too easy to inherit. Without a clear matrix, teams often end up with agents that can discover data, move data, and act on data using the same permissions, which weakens least privilege and makes incident containment harder. That risk is especially important in environments with Non-Human Identity governance, where the agent itself becomes a managed identity with distinct access conditions. NIST’s identity guidance is relevant here because assurance, authorization strength, and lifecycle control all influence whether an agent should be allowed to act at a given tier. For organisations that operate regulated or high-risk systems, mapping the matrix to recognised control logic such as NIST SP 800-53 helps make the model auditable and enforceable.
The real security value is that it forces explicit decisions about what an agent may do, under which conditions, and with what oversight. Organisations typically encounter the consequences only after an overprivileged agent has already moved sensitive data or triggered an unauthorised action, at which point the function-and-trust matrix 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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege map directly to runtime agent authority. |
| NIST SP 800-63 | AAL2 | Assurance levels inform how much confidence is needed before an identity can act. |
| NIST Zero Trust (SP 800-207) | PEP | Policy enforcement points are where trust-based decisions are applied to agent requests. |
| OWASP Non-Human Identity Top 10 | NHI governance covers lifecycle and privilege control for non-human identities. | |
| NIST AI RMF | GOVERN | GOVERN addresses accountability and oversight for AI systems and their operators. |
Treat agents as governed non-human identities with explicit scope, trust, and rotation controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
