No. Trusted automation should be permitted and optimised where there is confidence in identity, purpose, and behaviour. Untrusted or newly seen automation should face tighter scrutiny, challenge steps, and stronger monitoring until trust is established. Using one control model for both increases friction for legitimate workflows and reduces resilience against malicious activity.
Why trusted and untrusted automation need different control paths
The core issue is not whether automation is “good” or “bad”, but whether the organisation has enough confidence to let it act with reduced friction. Trusted automation is usually known, registered, and governed, so controls can focus on continuity, least privilege, and rapid detection of drift. Untrusted automation, by contrast, needs more verification because its identity, provenance, intent, or behaviour may not yet be established. That distinction matters most where automation can read data, trigger workflows, or call downstream systems on behalf of the business.
When teams apply the same control model to both categories, they often create one of two failures: they either over-restrict legitimate automation and push users toward unsafe workarounds, or they over-trust unfamiliar automation and leave a path for abuse. A control design that distinguishes trust level is closer to a risk-based access model than a blanket allowlist. For a control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it separates control intent from implementation detail, letting organisations tune access, monitoring, and verification to the trust level involved. In practice, many security teams discover the weakness only after a new automation path has already been granted the same standing as a long-established one.
How the control model changes as trust increases
Trusted automation should not mean “no controls”; it should mean “controls optimised for known behaviour”. The organisation still needs ownership, logging, scope limitation, and a clear revocation path, but the control burden can be lighter when the automation is well understood and its purpose is stable. That might include narrower challenge steps, automated approvals for routine actions, or lower-friction policy checks where the identity, workload, and permitted actions are already bound together.
Untrusted automation should be treated as provisional. Before it is allowed to act broadly, practitioners should verify what it is, who owns it, what data it can reach, and whether its behaviour is consistent with the declared use case. This is especially important where the automation is newly deployed, externally sourced, self-modifying, or capable of composing actions across tools. In those cases, the control model should emphasise stronger challenge, tighter policy scoping, more frequent review, and monitoring that can detect both misuse and unexpected expansion of behaviour. The right question is not “does it have access?” but “has it earned the same access model as established automation?”
- Trusted automation benefits from streamlined authorization when identity, purpose, and scope are already verified.
- Untrusted automation should be isolated until its behaviour, ownership, and data reach are proven.
- Monitoring should look for changes in purpose, permission creep, and unexpected tool use.
- Revocation should be immediate and operationally simple for both categories.
The approach breaks down when organisations cannot reliably distinguish trusted from untrusted automation in their inventory or when ownership and purpose metadata are missing.
Where the distinction breaks down, and what teams should watch for
Tighter control for untrusted automation often increases operational overhead, so organisations have to balance security confidence against workflow friction. That tradeoff becomes sharper in environments with frequent onboarding of scripts, bots, integrations, and AI-enabled agents, where the trust level may change faster than the control catalogue is updated.
One common edge case is automation that starts as untrusted but quickly becomes business-critical. That should not automatically earn permanent trust. Teams should treat trust as conditional on evidence, not on convenience or elapsed time. Another edge case is hybrid automation, where one component is well governed and another is externally supplied or loosely managed. In that case, the weaker component should set the control posture, because the composite workflow is only as trustworthy as its least governed part. The practical lesson is that trust is not a label that can be applied once and ignored; it is a state that needs periodic revalidation as the automation, data, and permissions change.
When organisations fail here, the usual pattern is either overconfidence in familiar automation or blanket suspicion that blocks useful work. Neither is stable for long.
Risk and Threat Considerations
Using one control model for all automation creates exposure in both directions: it can under-protect unfamiliar automation and over-constrain established automation. The first problem increases the chance that a newly introduced or externally influenced automation path can be abused for unauthorised data access, workflow manipulation, or unintended downstream actions.
Failure mechanism: attackers and internal abuse cases often benefit when automation is granted broad standing before its behaviour, ownership, or scope is fully validated. If the environment does not distinguish trusted from untrusted automation, excessive privilege, weak challenge steps, and poor monitoring can let misuse blend into normal operations.
Impact: the organisation may lose control over who can trigger actions, what systems those actions can reach, and how quickly suspicious behaviour can be detected or revoked. Operationally, this can produce both security exposure and avoidable friction for legitimate automation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Trust-based automation needs differentiated access decisions. |
| Recommendation — Apply PR.AC to vary access rigor by automation trust level. | ||
| CIS Controls v8 | 6 — Access Control Management | Automation trust depends on account and permission governance. |
| 8 — Audit Log Management | Untrusted automation requires stronger visibility into behaviour. | |
| Recommendation — Use Control 6 to separate trusted automation from provisional access. Use Control 8 to log and review automation actions and drift. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Abuse often occurs when automation is treated as equally trusted. |
| Recommendation — Map suspicious automation use to T1078 and hunt for account misuse. | ||
| OWASP Agentic AI Top 10 | A1 — Agent Access Control | Agentic or automated actors need trust-sensitive authorization. |
| Recommendation — Apply A1 to restrict untrusted automation until it proves reliability. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Trust depends on knowing what automation exists and who owns it. |
| Recommendation — Use NHI-01 to inventory automation and assign accountable ownership. | ||
Practitioner Guidance
What to prioritise: separate trust classification from mere presence in inventory. The useful decision is not whether automation exists, but whether it has enough evidence of identity, ownership, and stable purpose to earn a lighter control path.
Decision rule: if the automation is newly seen, externally supplied, poorly documented, or capable of expanding its own reach, treat it as untrusted until it has demonstrated stable behaviour over time. If it is established, bounded, and well owned, streamline the controls that add friction without improving assurance.
What good looks like: trusted automation is easy to recognise, easy to revoke, and hard to repurpose outside its approved scope. Untrusted automation is visible, constrained, and monitored closely enough that an unexpected change in purpose or behaviour becomes actionable.
Practitioner takeaway: mature control design does not use one uniform standard for all automation; it uses trust to decide where friction is useful and where it is just operational drag.
Related resources from NHI Mgmt Group
- Should organisations use the same identity controls for patients and clinicians?
- Should organisations use the same controls for humans, NHIs, and AI agents?
- Should organisations use the same identity controls for internal agents and customer authentication?
- Should organisations use the same controls for human-written and AI-generated code?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
