Trust and automation.
Consider a security system that identifies an account for review and has the technical permissions needed to disable it. The organization still needs to establish whether disabling that account is appropriate and who can authorize the change. Having the ability to act does not settle the decision.
That is where I would start when deciding how much security work to automate. Collecting information, recommending a response, and carrying out a change involve different responsibilities. A team needs to understand those responsibilities before giving software access to a live environment.
Start with the repeatable work
A defined task gives automation something specific to do. Software can retrieve directory records, compare them against a condition, and flag the accounts that match. It can record the results and repeat the check without requiring someone to work through the directory by hand.
This kind of automation is useful when the inputs, rules, and expected results are clear. Finding accounts that meet a condition gives a reviewer a starting point. Deciding what should happen to those accounts may require information that the rule does not contain.
The evidence may not explain the account
Imagine an account with administrator privileges and no recent activity in the records being reviewed. The access may be obsolete, or the account may support an infrequent business process. Someone may have approved the privilege for a reason that is not recorded in the identity platform.
The reviewer needs to establish which explanation applies. That could involve a manager, an application owner, an internal policy, or another source of business context. The absence of observed activity is a reason to investigate, not enough information to conclude that disablement is appropriate.
The review should distinguish observed facts from unanswered questions. It should also preserve the reasoning behind the eventual decision, including a decision to retain access or request more information.
Authority needs to be explicit
Before software changes an account, the organization needs to define who can approve that action and under what conditions. A person responsible for reviewing access may not be authorized to approve every change. The application owner may also need to explain what would be affected.
For an account-disable workflow, the authorization should identify the account and the specific action being approved. It should be clear which evidence informed the decision and whether any questions remain unresolved. The administrator or software carrying out the change should be able to refer to that authorization.
Adding an approval button does not establish these decision rights. The organization has to define them, and the process has to make them understandable to the people using it.
Human oversight should have a purpose
A person who clicks Approve without seeing the evidence has little basis for evaluating the request. Meaningful review requires enough information to understand what was observed, why it deserves attention, and what the proposed action would change. The reviewer should also know where the information came from and what has not been confirmed.
NIST’s AI Risk Management Framework calls for documented roles and responsibilities, including defined arrangements for human oversight of AI systems. That is a useful reference when deciding who reviews a recommendation and who has authority to act. AIRC
The reviewer also needs a way to decline the action or request more information. When evidence is incomplete, the process should allow the decision to remain unresolved. Approval should reflect an informed decision, rather than being the easiest way to clear an item from a queue.
Check what happened after the action
Suppose an authorized workflow sends a request to disable an account and receives a successful response. The next step is to read the account’s state from the source system and compare it with the intended result. The record should identify which account was checked, when the check occurred, and whether it showed the expected state.
A mismatch requires follow-up. So does a check that fails or cannot establish the result. The workflow should preserve that uncertainty instead of treating an unavailable answer as success.
The scope of the check matters, too. Confirming that the account was disabled at that time does not establish that every related system changed or that another process will never re-enable it. Keep the result specific so a later reviewer can understand what was actually verified.
Plan how recovery would work
A reviewer may approve a change with incomplete context, or an action may have an effect the team did not anticipate. Where recovery is possible, it should be understood before the original action occurs. That includes knowing who can authorize recovery and what state the recovery process is intended to restore.
For an account-disable workflow, define how re-enablement would be requested, approved, and carried out. Check the account state afterward and preserve the recovery record alongside the original action. Be clear about the limits of that recovery step rather than describing it as a way to undo every consequence of the disablement.
AI could help prepare the review
AI could help organize evidence around an identity condition, summarize relevant records, or identify questions a reviewer needs to answer. Those are possible ways to reduce preparation work while leaving the decision with the person responsible.
The reviewer should still be able to inspect the underlying records and distinguish source information from the system’s interpretation. A summary should make missing context easier to notice, rather than covering it with a confident recommendation. Whether that assistance makes a review faster or more useful needs to be tested in the workflow where it will be used.
The account example connects these responsibilities: finding a condition, deciding whether a response is needed, carrying out an authorized change, and checking the result. Operational Zero Trust looks more closely at how those steps fit together and what evidence should remain between them.
Where TPZ fits today
When configured for live access, TPZ can read supported Microsoft Entra and Azure identity and access information, subject to permissions and current coverage limits. This starting point is read-only and does not include changing a customer’s Entra environment. Its current AI chat can discuss supplied page data, but it does not have tools to carry out actions.
The Design Partner Beta is designed to begin with an evidence-backed Microsoft Entra identity and access audit. It is intended to progress toward a customer-authorized account-disable action, followed by read-back verification and retained evidence. The target also includes an authorized re-enable process with verification of the restored state. That action-and-recovery workflow remains a Beta target, not functionality the current product already provides.
The program is intended to test the work around that action, including the evidence a reviewer needs and how authorization should be recorded. Testing verification and recovery should also help establish what information needs to remain available afterward. These are questions to investigate before making claims about broader automation.
Walk through one action before enabling it
Choose one action your team is considering automating, such as disabling an account. Write down the evidence required, who can authorize it, and what the software is allowed to change. Then describe how the result will be checked and what should happen if it is wrong or cannot be confirmed.
Walk through that process with the people responsible. Ask them to consider a case where the evidence is incomplete and another where the action succeeds but recovery is needed. Any disagreement about the target, approval, or recovery is something to resolve while the workflow is still being designed.
