Should organisations use the same controls for trusted automation and untrusted automation?

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 This Matters for Security Teams

Trusted and untrusted automation should not be governed with the same control intensity because the risk is not just about what the workload can access, but how predictably it behaves. A known, bounded automation path can often operate safely under stable entitlements, while newly introduced or externally facing automation may require stronger verification, shorter-lived credentials, and tighter monitoring. This distinction matters because NHI exposure is already pervasive: NHI Mgmt Group reports that Ultimate Guide to NHIs found 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

Security teams often overcorrect by applying human-centric approval models to every workload or, conversely, by trusting all automation once it is “internal.” Neither approach scales well. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports tailoring control selection to risk, which is especially important for NHIs because their access patterns are machine-speed and often persistent. In practice, many security teams encounter privilege misuse only after an automation path has already been reused, chained, or copied into a less controlled environment, rather than through intentional review.

How It Works in Practice

A practical model starts by classifying automation into trust tiers, then binding controls to that tier rather than to the technology label. Trusted automation is typically a known workload with an approved purpose, stable ownership, and observed behaviour that matches its stated function. Untrusted automation includes new deployments, third-party integrations, copied scripts, and anything that can change scope without a human review gate.

That usually means different controls at three layers:

• Identity: issue workload identities for automation that can be uniquely authenticated, rather than shared service accounts.
• Credentialing: use short-lived secrets and just-in-time access for untrusted or newly seen workloads, then revoke automatically after use.
• Authorisation: evaluate policy at request time, not only at onboarding, so access matches the task being attempted.

This is where Zero Trust thinking becomes useful. The core idea is not to assume trust because something is inside a network zone, but to verify identity, context, and purpose continuously. The NIST Zero Trust Architecture model supports this direction, and the Ultimate Guide to NHIs — Standards reinforces that rotation, visibility, and least privilege are foundational for non-human access. For trusted automation, the control objective shifts from heavy challenge steps to continuous validation, anomaly detection, and scoped entitlements. For untrusted automation, the goal is to reduce blast radius until the workload proves stable. These controls tend to break down when identical credentials are reused across environments because the trust tier becomes impossible to verify at runtime.

Common Variations and Edge Cases

Tighter controls often increase deployment overhead, requiring organisations to balance operational speed against assurance. That tradeoff becomes sharper in environments where automation changes rapidly, such as CI/CD pipelines, multi-agent systems, or outsourced integrations.

Best practice is evolving, but current guidance suggests a few important exceptions. Mature internal automation may justify broader standing access if it is tightly bounded, heavily monitored, and owned by a clear operator. Even then, that trust should be revisited after code changes, ownership changes, or dependency changes. New automation should not inherit the same access model simply because it was built by the same team. Likewise, third-party or externally triggered automation should be treated as untrusted until its identity, purpose, and failure modes are validated.

There is no universal standard for how many tiers every organisation should use. Some use two classes, trusted and untrusted. Others add a probationary state for newly launched automation. The right model depends on how quickly the workload can change, how much privilege it needs, and how costly a false trust decision would be. The practical test is simple: if an automation path could laterally move, chain tools, or persist access beyond its intended task, it should not be treated like stable trusted automation from day one. That is exactly where the distinction between control models matters most.

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?