Put Policy Between People and the Model

Policy should sit between your people and the model.

Not as a training slide. Not as a quarterly attestation. As a control that evaluates before a prompt or agent action runs and leaves a record afterward.

That is the difference between AI governance as a workshop and AI governance as an operating system for regulated enterprises.

The false choice: block everything or allow blind

Most security and risk teams inherit the same deadlock:

Blocking without discovery pushes usage underground. Allowing without controls creates an evidence gap you can’t defend. The third path is the only one that scales with how employees and agents actually work.

What “policy before execution” means

In classical application security, we don’t rely on developers remembering the secure coding standard at runtime. We put checks in the path: authentication, authorisation, input validation, DLP.

AI usage deserves the same instinct.

Before execution means: when a user or agent is about to send a prompt, call a tool, or invoke a model, a policy decision happens first (allow, block, redact, route, or escalate) based on who they are, what data is involved, which tool they’re calling, and which policy pack applies.

After execution means: the decision and relevant context are logged in a form you can retrieve for audit, incident response, and board reporting.

If your “AI policy” only exists in SharePoint, you have intentions. If it evaluates in the path and logs outcomes, you have a control.

Anatomy of a governed interaction

A useful mental model for security and GRC leaders:

1. Identity: human user, service account, or agent identity.
2. Channel: browser assistant, IDE copilot, API, agent harness, embedded SaaS AI.
3. Payload risk: detected sensitive data, prohibited topics, high-risk use cases.
4. Policy pack: the organisation’s rules for that context (your “AI constitution” in enforceable form).
5. Decision: allow / block / redact / route / escalate.
6. Model or tool call: only if permitted.
7. Record: what happened, under which policy version, attributed to whom.

Skip steps 4–5 and you are hoping. Skip step 7 and you cannot assure.

Kinnatic’s capability order matches this lifecycle: Discover → Govern → Assure. Discovery tells you which channels and tools matter. Govern puts policy in the path. Assure makes the trail defensible.

Policy packs beat one-size principles

Enterprises don’t need a single essay titled “We use AI responsibly.” They need packs that encode different postures for different contexts, for example:

• Productivity assistants with corporate data: allow with redaction of defined sensitive classes.
• Customer-facing decision support: stricter escalation and human accountability.
• Software engineering agents: controls on repository access, secrets, and production change paths.
• Blocked categories: clear deny lists where risk appetite is zero.

Principles inform packs. Packs enforce. Enforcement produces evidence.

Avoid two failure modes:

• Pack theatre: hundreds of rules nobody can explain; users bypass the channel.
• Pack emptiness: three slogans with no evaluable conditions.

Start with a small number of high-clarity rules on the highest-sensitivity channels you discovered. Expand once operating effectiveness is visible in the logs.

Agents raise the stakes

In 2025–2026, “AI use” stopped meaning only a human chatting with a model. Agents plan, call tools, hold credentials, and act across systems. A policy that only reviews monthly use-case documents cannot govern actions that complete in seconds.

For agents, policy-before-execution is not optional rhetoric; it is how you prevent a compromised or mis-specified agent from becoming a master key. Industry discussion (from AI governance and AI security vendors alike) increasingly focuses on harness-level controls, tool-call gating, and composition risk when agents connect to MCP-style servers. The governance implication for enterprises is straightforward: treat agent actions as in-scope runtime events, not as documentation footnotes.

You still start with discovery: which agents exist, which tools they can call, which identities they use. Then you govern the path. Then you assure.

What CISOs should demand from any AI governance approach

Whether you build, buy, or blend, insist on:

1. Coverage of real channels: not only the one sanctioned chatbot.
2. Pre-execution decisions with clear outcomes (including redact, not only allow/deny).
3. Identity attribution for humans and non-humans.
4. Policy versioning so historical actions remain interpretable.
5. Retrievable evidence for audit walkthroughs.
6. Fit for regulated entities: obligation-aware thinking (Australia’s scattered obligations first; EU exposure where relevant), not US/EU marketing pasted on.

Be wary of platforms that only score model cards, or only scan ML supply chains, if your immediate problem is employees and agents using tools without a control in the path. Those capabilities can matter later; they don’t replace governed runtime for day-to-day usage.

A 14-day path from deadlock to governed pilot

Days 1–3: Run discovery. List top tools by sensitivity × volume.
Days 4–5: Choose one channel for a governed pilot (often browser or a single agent harness).
Days 6–8: Encode a minimal policy pack (data classes to redact; tools to block; escalation for edge cases).
Days 9–11: Enforce in path; verify decisions appear in logs; fix false positives with owners, not by disabling controls wholesale.
Days 12–14: Walk through evidence with GRC/audit; decide expand / adjust / hold.

This is how you replace workshop theatre with operating proof.

Built for regulated enterprises

Kinnatic is an AI governance platform. We transform shadow AI into governed control: see which AI tools your team uses, enforce policy before AI execution, and keep an audit-ready trail.

Put policy between your people (and your agents) and the model. Learn more at kinnatic.ai.

Evidence, not intentions.