I start with one rule: block AI connections unless they have a clear purpose, a named owner and explicit approval. For an internal document-retrieval agent, that means allowing access to its approved search index - not every database it can reach.
My approach covers five steps:
- Map assets and dependencies: record identities, data sensitivity and access paths, then define zones and control points.
- Check each request: limit access by identity, permissions, destination and data scope. Being inside a zone grants no trust.
- Control agent actions: an allowed connection does not permit every tool call or data request.
- Assign responsibility: record approvals, version rules, review changes and expire temporary exceptions.
- Test before expanding: roll out in stages, log decisions and test failures, revoked credentials and incident procedures.
I start with one bounded workflow, then expand once permitted requests succeed and blocked requests stay blocked. Segmentation limits access; it does not replace other security controls or prove UK GDPR compliance.
::: @figure 
{Zero Trust for AI: Five-Step Microsegmentation Blueprint}
:::
Zero Trust Architecture & Microsegmentation Explained! đ
Deny Connections by Default and Approve Exceptions
Once identities and zones are defined, replace trust assumptions with checks for every connection.
Block inbound and outbound traffic unless a documented policy explicitly allows it. Define each dependency separately: source identity, destination, environment, protocol, port, method, data classification and allowed operation. Include supporting connections such as DNS, secrets retrieval and monitoring. Start in discovery mode to map legitimate dependencies, then turn undocumented or unapproved traffic into deny rules.
Enforce HTTP methods, tool arguments and data permissions at the application layer through an API gateway, tool broker, service mesh or authorisation service.[3][5]
Check Each Connection Before Allowing Access
Match each request to a verified workload, service, agent or user identity. Check identity, authentication strength, workload posture, purpose, destination, data sensitivity, session context, time and risk signals against the current policy version.
Grant only the narrowest permitted scope and duration. Use short-lived credentials where supported, and reassess or revoke access when identity, risk, policy or resource conditions change.[2][4]
Log the requester identity, source and destination, protocol and method, requested resource, data-sensitivity label, policy version, timestamp in UK format, decision, decision reason, credential or session ID and enforcement point. For denied or reviewed requests, also record the missing evidence or failed condition. This lets the owner investigate without granting broader access unnecessarily.
Limit Agent, Model and Data Connections
Give agents an egress allow-list limited to approved destinations, DNS names or service identities, protocols and ports. An approved connection permits the path - not every tool action. Validate arguments, user permissions, tenant boundaries and data scope outside the model. Keep tool credentials in code-controlled services.[3][5]
Block arbitrary IP targets and unapproved webhooks unless separately approved. Deny development access to production data, and deny model-serving access to training stores, secrets and management interfaces, unless specifically approved.
Compare Allow, Deny and Review Decisions
Allow a connection only when every required condition matches. Deny it when a condition fails or no rule applies.
Review applies when evidence is incomplete, the flow is new or the request exceeds the policy ownerâs scope. Keep reviewed traffic denied until the owner approves the change and the policy is deployed.
Use these rules as the minimum evidence for approval.
| Connection | Approval condition | Required evidence | Enforcement point | Escalation owner |
|---|---|---|---|---|
| Agent â tool/API | A named agent identity has a documented purpose, the tool is approved, requested data is within the permitted sensitivity level and the user or workflow authorises it | Agent workload identity, user or workflow context, tool scope, destination, method, data classification | Egress firewall or service mesh plus API/tool gateway | Agent or application owner |
| Model service â vector store | The serving identity is approved for the specific index; retrieval stays within tenant and sensitivity limits | Service identity, index owner approval, query scope, tenant boundary, retention requirements | Service mesh or gateway plus vector-store authorisation | Model owner and data owner |
| Training job â data lake | The job identity, training purpose and dataset are approved; data is within the permitted classification and the environment is approved | Dataset register, data-owner approval, transformation or de-identification evidence, job definition, time limit | Data-access gateway, lake policy and workload identity control | Data owner; governance lead for sensitive data |
Assign Policy Owners and Manage Changes
Once a connection is approved, bring it under change control.
Every permitted connection needs a business case and an accountable owner. Let workload teams manage their dependencies, while central security sets minimum controls and approves exceptions. Keep each rule under version control, recording who requested, approved, implemented and reviewed it. Use the register as the single source of truth for regular reviews.
Document Each Approved Connection
Keep a central register covering source and destination identities, trust zones, purpose, protocol, port, direction, data class, authentication and authorisation requirements, enforcement point, owners, policy version, evidence, approval date and review date.
Use clear dates such as 16 October 2026.
Explain why the access is needed and why narrower access would not work. A label such as âAI accessâ is not enough.
Separate Approval and Enforcement Roles
Application owners justify dependencies. Security owners set standards and approve exceptions. Platform owners deploy controls and maintain enforcement. Data owners approve sensitive-data access and handling controls. Name a primary and deputy for each role.
In a smaller UK business, one person may hold several roles, but record each responsibility separately. The requester must not be the sole approver of a high-risk connection. Require independent security or management review, and keep approval separate from implementation.
Review Changes and Expire Exceptions
Require change control whenever an agent, tool, model endpoint, data source or external integration is added or changed - even if the service name stays the same. Reassess connections after architecture changes, incidents or shifts in data sensitivity.
Set risk-based recertification intervals, reviewing high-risk connections more often than lower-risk rules. Use usage evidence to remove rules that are no longer needed.
Give every temporary exception an owner, compensating controls, a rollback method and an explicit end date. Send expiry alerts and disable expired exceptions unless formally reapproved.
Test, Deploy and Maintain Policies
Observe Traffic and Enforce in Stages
Once a connection is approved, test it through staged enforcement using the default-deny policy and dependency map defined above. Start in discovery-only mode, then move through validation, limited enforcement and expansion.
Compare observed identities, paths, ports, protocols, classifications, request rates and outcomes with the dependency map. Traffic is evidence to investigate, not permission to connect. Test proposed rules outside production or in shadow mode before enforcing them for one controlled workload group.[1] Prioritise sensitive data stores, exposed services and privileged agent tools.
Before enforcement, check identities, documented dependencies, approval in the policy register, test results and log delivery. Record the rollback version, authorised operator, isolation procedure and on-call contact.
Test normal inference, retrieval, tool calls, model-to-model communication, scheduled jobs and failure handling. Move from limited enforcement to full rollout only when legitimate transactions succeed and expected denials work correctly.
Measure Coverage and Test Failures
Track identity coverage, enforcement coverage, blocked legitimate requests, unapproved access attempts, stale rules, exceptions and remaining lateral movement paths. Report results by workload and data sensitivity, measuring only against mapped assets and paths.
Set internal targets using the inventory and dependency map. No universal coverage percentage proves that segmentation works.
Use the results to guide recertification, rollback and incident response. Test policy engine or enforcement point outages, loss of identity-provider connectivity, compromised workload identities, revoked or expired credentials, unexpected destinations proposed by the model and logging outages.
Document whether established sessions terminate, continue or require reauthorisation. Sensitive access should normally fail closed.[6] Treat failed tests as policy defects, not just infrastructure issues. Feed failures into incident-response playbooks, assign named responders and update relevant data protection impact assessments. Segmentation supports security and accountability, but it does not prove UK GDPR compliance.[7]
Conclusion: Start with One AI Workflow
Choose one bounded workflow with a clear business purpose and limited dependencies.
For example, start with an internal document-retrieval agent.
Once enforcement is stable, automate regression tests and compare policy-as-code changes with the dependency inventory. Review permissions periodically, expire unused exceptions and block deployments that lack required identities or approvals.
Hokstad Consulting can support AI strategy, transformation and custom agent implementation, but policy ownership and final approval remain with your organisation.
FAQs
Can microsegmentation contain a prompt-injection attack?
Microsegmentation alone cannot contain prompt injection. It limits lateral movement and isolates workloads at the network level. But attackers can still manipulate agents into misusing authorised permissions at the application or logic layer.
Enforce controls at the platform level: validate tool calls against schemas and policies before execution, give each agent its own identity with tightly scoped permissions, and use short-lived, task-specific credentials. Prompts alone arenât enough.
How can I approve dynamic agent connections safely?
Use zero-trust, identity-based segmentation instead of static IP rules. Start with 30â60 days in audit-only mode to establish a baseline of legitimate traffic. During this period, log potential disruptions without blocking connections.
Once youâve validated the baseline, apply default-deny policies that allow only the interactions you need. Use policy-as-code to automate enforcement, and check new connections against predefined security standards in your CI/CD pipeline before authorisation. Use mTLS to continuously authenticate every service connection.
How do I balance strict access controls with AI performance?
Use dynamic, context-aware authorisation instead of static, session-based rules. Keep policy decisions separate from agent logic to reduce bottlenecks and latency.
Save resource-heavy checks for critical, high-risk tasks. For lower-priority workflows, use lighter, automated enforcement. Test new policies in shadow mode before switching them on in production. Use identity-based microsegmentation to isolate workloads and enforce least privilege without slowing performance.