A three-tier security model for IT automation is a risk-based governance framework that categorizes automated operations into three levels based on their potential impact: Tier 1 (read-only operations, auto-executed), Tier 2 (state-changing operations, requiring admin enablement), and Tier 3 (privileged operations, requiring explicit confirmation per execution). This model ensures that IT automation operates within defined safety boundaries while maintaining a full audit trail.
The pitch for IT automation is simple: let software handle repetitive tasks so your team can focus on complex problems. The pitch is also incomplete. It glosses over a critical question: what happens when the automation does something wrong? A human analyst who resets the wrong user's MFA methods gets a talking-to. An automation system that resets MFA for a dozen users because of a classification error creates a security incident.
This is the core tension of IT automation: the actions that save the most analyst time are also the actions that carry the most risk. Password resets, license changes, group membership modifications, mailbox permissions — these are not read-only operations. They change the state of your identity and access infrastructure. Without guardrails, automation becomes a liability.
This article explains the three-tier security model we built for Support Team and why each tier exists. Whether you build or buy your automation, this framework will help you design governance that your security team can actually approve.
Most IT automation tools offer a binary choice: on or off. Either the automation is allowed to execute actions, or it is not. This forces IT teams into an uncomfortable trade-off:
Neither option is right. The correct answer depends on what action is being taken. Checking a user's license status is zero risk — read-only, no state change. Assigning an E3 license is low risk — reversible, limited blast radius. Deleting an admin account is extreme risk — irreversible (within a time window) and potentially catastrophic. Treating these the same is a design failure.
The three-tier model assigns every automation action to a risk tier, and each tier has different execution rules. This is not a new concept in security — it mirrors how cloud IAM systems handle permissions (viewer, editor, admin). Applied to IT automation, it looks like this:
Tier 1 actions are read-only or trivially reversible. They execute automatically with no human approval required. The automation reads the ticket, takes the action, and updates the ticket — all within seconds.
Examples of Tier 1 actions:
Why these are Tier 1: Either no state change occurs (read-only), or the state change is immediately reversible and does not elevate privileges. A password reset is reversible because the user must set a new password on next login. Adding someone to a distribution group is reversible with a single API call.
Tier 2 actions change the state of a user's account or access in ways that carry moderate risk. They are not automatically executed — an admin must enable these action types for the tenant, and depending on configuration, individual executions may require approval.
Examples of Tier 2 actions:
Why these are Tier 2: These actions have a meaningful blast radius. Removing someone's license can delete their data after a retention period. Granting mailbox access exposes confidential information. Resetting MFA without proper identity verification is a common attack vector. These actions need an approval step or at minimum a deliberate admin decision to enable them.
Tier 3 actions are high-privilege operations that require explicit confirmation for every execution. Even if the automation is confident in the classification, it stops and waits for a human to approve the specific action on the specific account.
Examples of Tier 3 actions:
Why these are Tier 3: The consequences of a mistake are severe and potentially irreversible within normal business operations. Deleting an admin account or modifying conditional access policies can lock out entire departments. These actions should always require a human in the loop, regardless of automation confidence.
The tier assignment is not fixed globally — it is configurable per tenant. An organization with strict security requirements might classify license assignments as Tier 3 (explicit confirm). A fast-moving startup might classify MFA resets as Tier 1 (auto-execute). The model provides the framework; each tenant sets the dials.
In multi-tenant environments — MSPs managing dozens of clients, or enterprises with separate tenants for different business units — governance must be independently configurable per tenant. What is acceptable for one client is unacceptable for another.
Per-tenant governance means:
This isolation is not just a feature — it is a compliance requirement. SOC 2 Type II, ISO 27001, and most client contracts require demonstrable data and access isolation between tenants. If your automation tool shares configuration or data across tenants, you have a compliance gap.
An audit trail for IT automation needs to answer five questions for every action taken:
Every audit record should be immutable — once written, it cannot be edited or deleted, even by administrators. This is a hard requirement for SOC 2 and most security frameworks. In Support Team, audit logs are written to an append-only data store with retention policies configurable per tenant.
Security teams are the gatekeepers for any automation that touches identity and access. Getting their sign-off requires more than a feature demo — it requires addressing their specific concerns:
Invite your security team to review the automation before you pilot it. Give them read access to the audit logs and let them observe Tier 1 actions running in production before you enable Tier 2. This staged approach builds trust incrementally and surfaces concerns early, when they are cheap to address.
Whether you build your own automation or use a managed platform, the three-tier model is straightforward to implement. The key design decisions are:
Support Team implements all five of these design decisions out of the box. Each tenant has a governance dashboard where administrators configure which actions are enabled, at which tier, and who approves. The audit trail feeds into the reporting dashboard and can be exported to external SIEM tools. And the staged rollout is built into the onboarding process — every new tenant starts with conservative settings and promotes actions to lower tiers as confidence builds.
Requiring approval for every automated action defeats the purpose of automation. If a read-only user lookup needs approval, your queue fills with approval requests and analysts spend time clicking "approve" instead of resolving complex issues. The three-tier model concentrates human oversight where it matters — state-changing and privileged operations — while allowing safe operations to execute freely.
Ask two questions: Is this operation reversible? And what is the blast radius if it goes wrong? Read-only operations (Tier 1) have zero blast radius. State-changing operations like license assignment (Tier 2) are reversible with limited impact. Privileged operations like account deletion (Tier 3) are irreversible or high-impact. When in doubt, place it one tier higher — you can always move it down after gaining confidence.
Yes. Per-tenant governance means each customer organization independently controls which Tier 2 and Tier 3 operations are active. One tenant might enable license assignment automation while another keeps it manual. This is critical for multi-tenant SaaS because each customer has different risk tolerance and compliance requirements.
Support Team enforces tiered security on every automated action — from read-only lookups to privileged account changes. Per-tenant governance, immutable audit trails, and kill-switch controls built in. Designed for IT teams that need automation their security team will approve.
See How It Works