Using decK and GitOps to Produce Change-Control Evidence for Kong AI Policies

What change-control evidence has to answer

An auditor reviewing a change to an AI policy asks four things. Who made the change? Who approved it? What exactly changed? When did it reach production? For Kong AI policies, such as AI Proxy and prompt or request-handling plugin settings, the answers are fragmented when changes are made through the Admin API or the UI. Those paths leave little reviewable context, and the live gateway can drift from whatever was last reviewed.

The pattern in this guide treats the Git repository as the system of record for configuration change history and approvals. Declarative decK state files hold the intended configuration. Every change is a pull request. The pipeline then produces outputs that are retained alongside the Git history.

This framing follows NIST's definition of an artifact as a piece of evidence, and of evidence as grounds on which to base proof. NIST guidance on secure software development also gives the example of tracking all changes with accountability to an individual account, approving changes made by others, and applying change control to configuration treated as code. Treat these as illustrative guidance, not as a mandated design.

Pipeline controls that make the artifacts trustworthy

An artifact is only as credible as the controls around it. Protect the branch that the sync runs from, and require review before merge. Attribute commits to individual accounts rather than shared ones. Where your Git platform supports it, add signed commits so authorship is verifiable. The exact reviewer and signing settings depend on the platform, so document the configuration you choose and keep that documentation with the evidence.

The most important control is credential scope. Only the pipeline should hold credentials that can write configuration to the gateway. If engineers retain direct Admin API write access, the Git history can be accurate and still incomplete. Where direct access cannot be removed, the drift check becomes the detective control that surfaces out-of-band changes.

There is also a design tradeoff. NIST guidance on policy as code recommends a pull-based GitOps model, in which a separate operator reconciles deployment from the main branch. A CI-driven diff and sync pipeline is typically push-based. You can narrow the gap by syncing only from the protected main branch, keeping sync credentials restricted to the pipeline, and running scheduled diffs as an approximation of continuous reconciliation. Record the choice and its rationale as a design decision.

Secrets, environment values and drift

AI plugin configuration often references provider credentials. Those values should not sit in plain text in state files, in pull request diffs or in archived outputs. Keep secret values in a dedicated secrets manager and inject them at sync time through whatever substitution or reference mechanism your Kong deployment supports. Keep environment-specific values, such as endpoints or model identifiers per environment, in separate reviewed files or variables so a single policy definition can be promoted without edits.

Evidence must stay complete without exposing sensitive data. Review what the diff and sync outputs print before archiving them, and mask sensitive fields in the pipeline so retained artifacts show that a credential reference changed without revealing the credential. Test this with a deliberate dummy change before relying on it.

For drift, run the same diff step on a schedule against each target and store the result even when it is empty. A retained empty result is evidence that the check ran and found nothing. Route non-empty results to an owner, and record whether the resolution was a reviewed pull request that adopts the change or a sync that restores the reviewed state. Without that follow-up, a drift report is only a notification, not a control.

What this evidences, and what it does not

Git and decK records evidence configuration change history. They show that a policy definition changed, who authored and approved it, what the difference was and when it was applied. This supports the change-management expectations that frameworks such as the NIST AI RMF place within post-deployment practices. Version control and document retention are also recognized in NIST's generative AI profile as ways to track change over time. Do not describe these records as a mapping to any specific audit standard unless your assessor has agreed to that mapping.

They do not show that a deployed policy enforced as intended, and they do not show what any individual AI interaction did. A merged and synced configuration proves the intended state, not the behavior of a particular request, response or tool call. Those questions need a separate evidence layer.

Trussed addresses that layer. It enforces policy in the execution path, with actions such as allow, redact and block, and produces audit-ready evidence of what happened at runtime. That evidence complements configuration change records: the pipeline shows how a policy came to be, and runtime evidence shows what was enforced on actual interactions. Keep the two record sets separate in your audit documentation so each is described accurately.