Zero Trust Done: Build Control Plane Before Ticket Agent Write Access?

Backend Authorization Must Be Verified Before Project Approval

Closing a ticket may stop upgrade notifications or trigger service assessments. The real prerequisite for changing a decision is whether the backend can answer: who delegated this Agent, which ticket to close, which fields are allowed to change, and whether the current state permits closure.

In a PoC a single wrong answer can still be filtered by a human. Once tools are integrated, retrieved malicious instructions may induce closure; cross-session memory may leak another department's ticket ID; retries after timeout may resend closure notifications. New attack surfaces are action paths and state pollution, so existing permission designs must be re-verified.

If legacy interfaces only recognize a shared service account, the backend sees that account, not the initiating employee. Putting the employee name into call parameters still requires a trusted service to verify the source; otherwise the model could generate a name and impersonate another user's privileges.

Once a tool can mutate business state, authorization must occur at the actual execution point and be bound to the object and parameters.

For example, prepare two tickets pending closure: A belongs to Operations, B to Finance. After an Operations employee is approved for A, swap the ticket ID in the tool parameters to B. Acceptance requires B to remain unchanged and the execution layer to log a rejection, not merely show "no permission" in the chat window.

The adaptation layer must query the authoritative ticket ownership and block direct paths to legacy interfaces. If both tickets can be closed, fix the execution boundary first before expanding the pilot.

If the existing zero-trust system already achieves this granularity, reuse it directly. If object ownership cannot be queried or write interfaces cannot be consolidated, keep read-only. Platform procurement cannot solve legacy business systems' authorization blind spots.

Single Scenario Dual-Track First, Shared Write Permissions Then Platform

Scenario-first suits a single-department read-only assistant: retrieval scope follows the employee's data permissions, and caches are isolated by tenant and permission. First test "tickets the employee cannot see, the assistant also cannot retrieve." This path validates business value quickly; when onboarding a second business domain, policy extraction and interface refactoring become necessary.

Platform-first suits enterprises that have already decided multiple teams will share tools, credentials, or high-privilege operations. Deliver common identity and policy interfaces first, then attach scenarios. The platform handles on-call, policy changes, and incident response; business teams retain ticket ownership and state migration rules; otherwise every new field requires a platform request.

The author prefers traditional enterprises to start with a dual-track transition: let 10 employees in one department try retrieval and handling suggestions, while closure stays in the original ticket UI. The platform side builds authorization and audit in parallel, temporarily maintaining two entry points. If Finance also wants to reuse the closure tool, promote the shared identity and policy interfaces to the platform layer.

Transition needs exit criteria: object-level authorization tests pass, approved parameters match actual calls, failed operations are traceable and compensable — only then open the closure tool to the Agent. If the human confirmation UI only shows "continue?" but hides the ticket ID and changed fields, it still lacks a valid approval basis.

Building control capabilities and building a full platform are two different construction scopes. Even a single scenario must hold its boundaries; when cross-team reuse demand appears, promote the already-verified capabilities to a shared layer.

Five Control Layers Must Reach the Execution End, Not Stay in Prompts

Identity layer links employees, Agent workloads, and delegation relationships. A task queues for five minutes; the employee is revoked at minute two. Execution must reject, not reuse the permission granted at enqueue time. The identity system and business services must agree on how revocation propagates to the execution end.

Tool authorization layer governs actions, objects, fields, and state preconditions. After approving ticket A version 12, a human updates it to version 13; the execution end must reject the stale approval. The execution end verifies normalized parameters and version, then atomically submits the version condition and state change.

Credential layer keeps long-lived credentials on the trusted proxy side; the model only outputs call intent. Even a 60-second sandbox token could be read within that window. Restrict target services and actions, and test with a request that swaps the target service to verify rejection.

Runtime isolation layer controls files, processes, session state, and network. Fixed tools can use a narrower execution environment; increase isolation strength when running generated code. Egress defaults to deny, allowing only model services and tool proxies on demand. Additionally test whether bypassing the proxy to connect directly to the ticket service fails.

Kubernetes NetworkPolicy is enforced by the supporting network plugin; allow rules in the same direction take the union. namespaceSelector combined with podSelector on the same rule is an intersection; splitting them into two rules expands the allow scope. Acceptance is verified by actual workload connectivity tests; domain and interface restrictions are delegated to respective egress controls.

Audit layer spans the previous four layers, recording request correlation ID, delegated principal, policy version, approval ID, tool parameter summary, and business outcome. Credentials and sensitive payloads are redacted; security audit logs are written to a location the Agent cannot modify. Otherwise wiping the runtime instance could also erase the only evidence.

These five layers form a control boundary surrounding the actual call; knowledge bases and ticket interfaces still handle business reads and writes. During integration, mark for each layer which existing system owns it, and only fill gaps — avoid creating parallel identity or logging systems.

The Costliest Gap During Coexistence Is Unclear Write Results

For instance, set the client timeout to three seconds, let the backend submit at second two, then drop the response. At this point "timeout" only means no result was received. Retry twice with the same operation ID; acceptance should show exactly one state transition, one closure notification, and the original operation result retrievable by that operation ID.

The operation ID serves as an idempotency key recognized by the service to detect duplicate requests; retries for the same business intent reuse it. If the same ID carries a different ticket or parameters, the service must reject. Idempotency records and business writes must be reliably linked to avoid a successful write leaving no deduplication record.

Place the ticket version or expected state into the update condition and execute atomically with the state change; on mismatch return a conflict and require re-confirmation. Notifications are designed separately for deduplication and compensation. When querying the original operation result, verify business state and notification delivery records independently.

Only when security thresholds are compared against the same yardstick does construction sequence become worth discussing. Scenario-first distributes maintenance to teams; platform-first adds shared dependencies and on-call burden; dual-track adds coexistence adaptation and handover work. Budgets must list these people and responsibilities, not estimate investment by component count.

Also rehearse policy service unavailability: new high-risk writes pause, manual original processes remain usable. When audit is temporarily unavailable, agree in advance whether a reliable buffer can ingest logs; if authorization and traceability cannot be guaranteed, stop automatic writes. The pilot owner must personally verify the fallback entry once.

Launch Review Checklist for the Closure Tool

The following review assumes "ticket Agent opens closure action." Each question requires a test record location and owner; missing items keep read-only or original manual flow. Question 6's acceptance script: "Discard response, retry twice; state transitions once, notification once; attach operation ID query record; owner: ticket service maintainer."

Who initiates, who executes, who delegates? After revoking employee permissions, are queued write tasks rejected?

Which tickets, fields, and states are allowed to change? When swapped to another department's ticket ID, which component rejects?

Who holds long-lived credentials? What can the sandbox access, and how is leakage contained?

How are session memory, files, and network isolated? Have cross-session ID leakage and proxy bypass tests passed?

Is approval bound to actual parameters? Can the same correlation ID retrieve policy version and business outcome?

How to handle successful write with lost response? Have idempotency, atomic state verification, and notification compensation been live-tested?

When a second business domain onboards, who maintains shared policies? During platform failure, who is responsible for stopping writes and taking over manually?

Read-only with controlled data scope first validates value via scenario; single write scenario first completes execution boundaries; shared demand clarified, then promote control capabilities to a platform. Writing migration triggers into the project charter is more useful than drawing a full target state upfront.

Tickets still write back via a shared account — should Agent closure permission be opened? Share your constraints in the comments.