The record as the DNS provider now serves it: name, value, and TTL.
Workflows · DNS changes
A DNS record change stops before production traffic moves.
CC8.1 evidence for a DNS change: the current and proposed record, the named approver and reason, and the provider's record read back.
Example workflow. Execution requires a configured tool with provider permissions for this action; see the connection’s operation reference or bring your company tool to the demo.
Agent request
Change api.example.com from 203.0.113.10 to 203.0.113.24
An incorrect record can route API traffic to the wrong endpoint or make it unreachable.
- Identity
- network-agent · Infrastructure
- Target
- production/api.example.com
- Cost
- Recorded agent cost
- Evidence
- Current record, proposed value, TTL, and rollback value
SOC 2 CC8.1
Sensitive: waits for a named approver.
The current and proposed record, the Network owner's reason, the record read back from the provider, and the CC8.1 test it supports.
Policy decision
Production DNS changes require the Network owner.
Network owner
The action waits until this owner approves or denies it.
Tool call resumes
The DNS provider receives the approved record change and returns its result.
Tool call stays blocked
The existing DNS record stays in place and the write does not run.
Execution order
The agent request stops before the connected tool runs.
- 01Network agent requests the record change
- 02Deixic checks the zone, record, destination, and policy
- 03Network owner decides
- 04Connected DNS tool returns the change result
- 05Deixic reads the result back and attaches the receipt to the test
Activity history keeps the request, decision, cost, and result.
Keep the procedure for the next request.
Keep the policy and decision history, save the steps and evidence as a skill, and test changes on real sessions; an approval stays specific to its request.