Predictika · IT Change and Access Check

Before an AI operations agent changes a system or grants access, the action is checked against the change and access rules

Corvane Freight IT, a fictional company, lets an AI operations agent work its change and access tickets. Before the agent implements a change or grants a role, the call goes to Predictika’s IT Change and Access Check. It checks that the ticket is open, assigned to the agent and covers the system, that the agent may take the action, the change window, CAB approval, standard-change eligibility, backout plan, freeze and redundant pairs, how critical the system is for this agent, and for access the role limits, contract, clearance, segregation of duties and an independent approver. It also checks that the end time, criticality and contract days the agent stated match the record. Then it returns one verdict: allow, needs approval, or block.

Illustrative only. Corvane Freight IT, its systems, tickets and people are fictional. Windows, limits, roles and contract dates are invented for this demonstration and are not IT policy guidance.

Scope: one change or one access grant, judged against ticket, window, agent and access rulesSee everything this validator covers

This validator decides one thing: whether one change or one access grant may go ahead, given what the agent proposes. It is not a ticketing system or a change calendar, and it does not run the change.

  • Actions — implement a change on one system, or grant one role to one person.
  • Rules — ticket status, owner and kind; agent permission; change window, CAB, standard changes, backout, freezes, redundant pairs; criticality against the agent limit; test evidence; emergency approval; role limits, contract, clearance, segregation of duties, approver; and the stated figures.

Within these rules the validator handles any combination of the listed choices, not just the eight scenarios on this page. It never sees the ticketing tool or the systems; their facts are taken from the records loaded into it.

What the validator sees: the action the agent proposes, plus the ticket, system and person recordsRead more

The validator takes the proposed action as inputs: the agent, the ticket, the system, the change type, the start day, hour and length, and the backout and test status for a change; or the person, the role, the days and the approver for a grant. The agent may also state the end time, the criticality or the contract days. The validator looks up the records and computes the rest.

Two honest limits. The validator judges the action it is given: if the agent names the wrong ticket, the answer follows it. And an action that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the ticketing workflow makes the call.

The AI agentProposes the action, says why it is fine, then calls the validator before acting.
Predictika validatorLooks up the ticket, system and person, applies the rules, then returns one verdict.

8 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where change and access tooling gets it wrong
Click to expand
    
General statements about ticketing and access tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

    
What the validator caughtTypical toolPredictika
Change windows and freezes kept per systemOnly with workarounds
Each system has its own window day and hours and its own freeze state. A ticketing tool usually shows them as notes, and a rule has to compare the planned start and length with them.		Every rule is checked on every call and the verdict lists each finding.
What an agent may do alone, by criticality and action typeOnly with workarounds
Limits by agent, system criticality and action type need several rules, plus an approval path when the limit is exceeded.		Every rule is checked on every call and the verdict lists each finding.
Redundant pairs and standard change modelsOnly if someone is vigilant
Rules such as never changing both halves of a pair, or allowing a standard change only where a model exists, are simple but must stay complete as systems are added.		Every rule is checked on every call and the verdict lists each finding.
Access limits from the role, the person and the contractCannot do it
A grant has to fit the role maximum, the person’s contract end, their clearance, the segregation-of-duties rules and an independent approver. Those facts live in different records.		Every rule is checked on every call and the verdict lists each finding.
Checking the facts the agent statedCannot do it
Comparing a stated end time, criticality or contract length with the record needs rules that compute them, and ticketing tools rarely check stated figures.		Every rule is checked on every call and the verdict lists each finding.
Ticket covers a different systemOnly if someone is vigilant
Each of these sits in a different system: the ticket record, the change model catalogue and the agent limits. A rule has to read them together.		Every rule is checked on every call and the verdict lists each finding.
Change outside its approved windowOnly with workarounds
A ticketing tool records the change window as a note. A rule has to read each system’s window, the start and the length together.		Every rule is checked on every call and the verdict lists each finding.
System in a change freezeOnly if someone is vigilant
A freeze is a calendar fact kept apart from the window. A rule has to read both before the change goes ahead.		Every rule is checked on every call and the verdict lists each finding.
Access longer than the role allowsOnly with workarounds
A role maximum and a contract end date come from different records. A rule has to compare the request with both.		Every rule is checked on every call and the verdict lists each finding.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

    
1Access control agent is not permitted to take this kind of action.
2Ticket CR3007 is closed. Do not act on a finished ticket; open a new one if more work is needed.
3Ticket CR3001 is not assigned to Tier 1 desk agent. Work only on tickets assigned to you.
4Ticket AR4001 is not a ticket for this kind of action.
5The ticket covers a different configuration item than the one the change targets (Datacenter router 01). Work only on the item named in the ticket.
6Perimeter firewall 01 may only be changed on day 7 between 2:00 and 6:00 (1 = Monday). This plan runs day 3 from 14:00 to 16:00.
7A normal change on Perimeter firewall 01 has no CAB approval recorded. Do not implement until the CAB approves.
8Datacenter router 01 has no pre-approved standard change model. Raise it as a normal change with CAB approval.
9Datacenter router 01 and Datacenter router 02 are the two halves of an HA pair. Change one, verify, then raise a separate change for the other.
10A production change on Edge load balancer 01 has no backout plan. Attach one before implementing.
11Ledger database 01 is in a change freeze. Only emergency changes are allowed.
12The agent stated criticality 2 for Perimeter firewall 01; the validator has it at criticality 5.
13The agent stated the change ends at 7:00; the validator computes 5:00.
14Ines Varga already holds a role that conflicts with AP payment release (segregation of duties).
15Production DB administrator can be granted for at most 10 days; the action asks for 30. Use a shorter, time-bound grant.
16Mira Solano is no longer an active employee or contractor. Access can only be granted to active users.
17Tobias Lund has 25 days left on contract; access for 30 days would outlive the contract.
18Noor Haddad approved their own access request. Someone else must approve.
19The request is still pending, not approved. Wait for approval.
20Cloud account administrator needs clearance 4; Noor Haddad has clearance 2.
21The ticket asks for a different person or role than this action grants. Act only on what the ticket requests.
22The agent stated 90 days left on contract for Tobias Lund; the validator has 25.
23Datacenter router 01 is criticality 5; this agent may change up to criticality 2 on its own. A human engineer must approve.
24No test evidence is attached for the change on Edge load balancer 01. A change manager must accept the risk.
25An emergency change on Ledger database 01 bypasses the window and freeze, so the Emergency CAB must approve it first.
26Cloud account administrator is a privileged role and this agent may not grant privileged access on its own. Route it to the IAM team.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Agent scope: A desk agent that wanders to a core system

    
The agent's request. I'm implementing ticket CR3003 as a standard change on the datacenter router on day 7 from 3:00 for 2 hours. It ends at 5:00 and the router is criticality 5.

    
Verdict: Blocked.

    
    
      
  • Ticket covers a different system. The ticket covers a different configuration item than the one the change targets (Datacenter router 01). Work only on the item named in the ticket.
    • 
      
  • Standard change not pre-approved for this system. Datacenter router 01 has no pre-approved standard change model. Raise it as a normal change with CAB approval.
    • 
      
  • System more critical than the agent may change alone. Datacenter router 01 is criticality 5; this agent may change up to criticality 2 on its own. A human engineer must approve.
    • 
    

    
2. Agent scope: The desk agent on the ticketed switch

    
The agent's request. I'm implementing ticket CR3003 as a standard change on the access switch on floor 2 on day 7 from 3:00 for 2 hours. It ends at 5:00 and the switch is criticality 1.

    
Verdict: Allowed.

    
3. Change windows: A firewall change on a weekday afternoon

    
The agent's request. I'm implementing ticket CR3001, a normal change on the perimeter firewall, on day 3 from 14:00 for 2 hours. The change has CAB approval, a backout plan and test evidence. It ends at 16:00 and the firewall is criticality 5.

    
Verdict: Blocked.

    
    
      
  • Change outside its approved window. Perimeter firewall 01 may only be changed on day 7 between 2:00 and 6:00 (1 = Monday). This plan runs day 3 from 14:00 to 16:00.
    • 
    

    
4. Change windows: The same change inside its window

    
The agent's request. I'm implementing the same change on day 7 from 3:00 for 2 hours. It ends at 5:00.

    
Verdict: Allowed.

    
5. Freezes: A patch during a change freeze

    
The agent's request. I'm implementing ticket CR3004, a normal change patching the ledger database, on day 7 from 3:00 for 2 hours. It has CAB approval, a backout plan and test evidence. It ends at 5:00 and the database is criticality 5.

    
Verdict: Blocked.

    
    
      
  • System in a change freeze. Ledger database 01 is in a change freeze. Only emergency changes are allowed.
    • 
    

    
6. Freezes: The same patch as an emergency change

    
The agent's request. I'm implementing the patch as an emergency change on day 3 from 11:00 for 2 hours. It ends at 13:00.

    
Verdict: Needs approval.

    
    
      
  • Emergency change needs the Emergency CAB. An emergency change on Ledger database 01 bypasses the window and freeze, so the Emergency CAB must approve it first.
    • 
    

    
7. Access grants: Database admin for a contractor, 30 days

    
The agent's request. I'm granting ticket AR4001: Production DB administrator to Tobias Lund for 30 days, approved by Felix Brandt. He has 25 days left on his contract.

    
Verdict: Blocked.

    
    
      
  • Access longer than the role allows. Production DB administrator can be granted for at most 10 days; the action asks for 30. Use a shorter, time-bound grant.
    • 
      
  • Access longer than the contract. Tobias Lund has 25 days left on contract; access for 30 days would outlive the contract.
    • 
    

    
8. Access grants: The same grant for 10 days

    
The agent's request. I'm granting the same role for 10 days. He has 25 days left on his contract.

    
Verdict: Allowed.

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Corvane Freight IT, a fictional company, lets an AI operations agent work its change and access tickets. Before the agent implements a change or grants a role, the call goes to Predictika’s IT Change and Access Check. It checks that the ticket is open, assigned to the agent and covers the system, that the agent may take the action, the change window, CAB approval, standard-change eligibility, backout plan, freeze and redundant pairs, how critical the system is for this agent, and for access the role limits, contract, clearance, segregation of duties and an independent approver. It also checks that the end time, criticality and contract days the agent stated match the record. Then it returns one verdict: allow, needs approval, or block.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I'm implementing ticket CR3003 as a standard change on the datacenter router on day 7 from 3:00 for 2 hours. It ends at 5:00 and the router is criticality 5.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with two findings and one approval, all in one answer. The ticket covers a different configuration item than the one the change targets (Datacenter router 01). Work only on the item named in the ticket. Datacenter router 01 has no pre-approved standard change model. Raise it as a normal change with CAB approval.
    6. 
      
  6. The validator returned two blocking findings and one approval in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
    7. 
      
  7. What this shows: for ticket covers a different system, a tool does this reliably only when someone is vigilant.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the system targeted to Access switch, floor 2 and the stated criticality to 1.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. All three earlier findings are cleared.
    13. 
      
  13. Three problems caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs. Now you can try the other scenarios yourself.
    14.