From AI policy to enforcement: controls your business can test

A written AI policy cannot stop an employee uploading a customer file or an agent making an unauthorised change. In its article on translating AI policy into technical enforcement, ThreatLocker highlights the need to connect governance decisions with system restrictions and monitoring. For Australian small and medium businesses, the practical question is whether AI governance controls enforce the rules when someone takes a shortcut or an integration behaves unexpectedly.

The goal is useful automation within defined boundaries: managed agents operating in a private Australian-hosted environment, with restricted access and human approval retained for consequential actions.

Start with AI governance controls you can test

Replace broad instructions such as “protect confidential information” with rules that identify the user, system, information and permitted action. Each rule needs an owner, an enforcement mechanism and a test.

For an invoice workflow, a workable requirement might be: the finance agent can read invoices in a designated intake location and compare them with purchase orders, but cannot change supplier bank details or release payments.

Translate that requirement into a control register:

| Business rule | Technical enforcement | Evidence to check | | --- | --- | --- | | Only approved staff can use the agent | Assigned identity groups and authenticated access | Group membership and sign-in records | | The agent only reads relevant records | Restricted connector and storage permissions | Permission review and denied-access test | | Financial changes require review | Approval gate before the write operation | Named approval linked to the transaction | | Data stays within approved boundaries | Restricted destinations and verified processing locations | Configuration review and network records |

Start with one workflow. Proving a narrow control is more valuable than publishing a broad policy nobody can verify.

Restrict tools, accounts and connection paths

Inventory more than standalone chat applications. Include browser extensions, embedded assistants, desktop software, automation platforms and integrations connected through staff accounts.

Maintain an approved-tool register recording the business owner, purpose, authorised users, permitted data and review date. Then enforce that register through the controls available in your environment:

• Restrict software installation and browser extensions on managed devices.
• Use identity groups to grant access to approved AI applications.
• Review app consent settings so staff cannot casually authorise broad access to business data.
• Apply web and network restrictions to unapproved services where technically feasible.
• Require managed devices for sensitive workflows where supported.

Website blocking alone is insufficient. Embedded features and direct API connections may follow different paths. Test desktop, browser and integration access separately, and document gaps rather than assuming every route is covered.

Give staff a usable alternative and an exception process. Our shadow AI governance guide explains why replacing unsupported tools matters alongside restricting them.

Make data permissions narrower than staff permissions

An agent should not inherit everything its sponsor can access. A finance manager might legitimately see payroll, banking and management reports, while an invoice-matching agent needs only selected purchasing records.

Use a dedicated workload identity where supported. Limit it to specific folders, sites, tables or API operations. Separate read permissions from write permissions, and avoid shared administrator accounts.

For a Knowledge and SOP Agent, check both the source repository and the search index. Removing access to a document may not immediately remove an older indexed copy. Define how permission changes, deletions and retention rules propagate through the knowledge environment.

AI governance controls should also prevent cross-user disclosure. Test whether a user without access to a restricted document can retrieve its contents through a question, summary or citation. Where a shared agent identity is used, the application needs an additional way to enforce each user's access boundaries.

Before connecting Microsoft 365, review overshared sites, guest access and broad groups. The Microsoft 365 hardening checklist provides a useful starting point for that wider configuration review.

Verify the private hosting boundary

Private Australian hosting is an important design requirement, but the location of the application server does not establish where every part of a workflow processes data.

Map the complete path: document storage, extraction services, model inference, search indexes, logs, backups and support access. An agent hosted locally could still send content to an external model endpoint if its configuration allows it.

For managed agents operating in a private Australian-hosted environment, ask:

• Where are prompts, attachments, outputs and embeddings processed and stored?
• Can any connector transmit content outside the approved environment?
• What retention settings apply to diagnostic logs and backups?
• Who can access production information for support, and how is that access approved?
• What contractual terms govern provider use of submitted information?

Restrict outbound connections to required destinations and keep credentials in a managed secret store, not prompts or scripts. Set a process for rotating credentials and revoking them quickly. Record any exception explicitly rather than treating “private” as a complete security specification.

Enforce human approval outside the model

A prompt telling an agent to seek permission is not an approval control. The workflow or destination system must prevent the action until an authorised person approves it.

For an AP/AR Automation Agent, this can mean preparing an invoice draft while leaving posting, payment release and supplier master-data changes outside its permissions. For an Outreach and Pipeline Agent, it means preparing follow-up messages for sales-team review rather than sending them automatically.

The approval screen should show the proposed change, supporting records, relevant exceptions and destination. Bind approval to the specific action and content. If the content changes afterwards, require another review.

Use these checks:

• The agent cannot approve its own request or use the approver's credentials.
• A rejected or expired approval cannot trigger an action.
• A failed approval service leaves the action blocked.
• Retrying a workflow cannot create duplicate transactions.
• Material changes invalidate an earlier approval.

Our guide to human approval in invoice processing explores that division between preparation and authorisation. Keeping review outside the model also limits the consequences of malicious instructions hidden in documents or web content.

Keep audit trails that reconstruct decisions

Useful AI governance controls produce evidence, not just activity counts. Give each workflow run a correlation identifier that connects the request, retrieved records, proposed action, approval and final system result.

Capture the requesting identity, agent version, connector activity, denied operations and approving person. Record timestamps and enough context to explain what changed without automatically copying sensitive document contents into logs.

Protect audit records from alteration by the agent. Restrict access, define retention periods and assign someone to review alerts. Repeated denied-access attempts, new external destinations and unexpected write operations deserve investigation.

Logging everything without an owner is not oversight. Agree who investigates, how they pause a workflow and when they escalate to the business owner.

Test enforcement before expanding automation

Before go-live, attempt the actions your policy prohibits. Ask the agent to retrieve a restricted file, connect to an unapproved destination and perform a write operation without approval. Include a document containing instructions to ignore its task or disclose unrelated information.

Record expected and actual results. Repeat tests after connector changes, permission changes and significant workflow updates. Maintain a practical stop procedure covering schedules, identities, tokens and pending actions; disabling a user interface alone may leave background jobs running.

Expand only when the business owner and technical owner can explain what the agent can access, what it cannot do and how they would investigate an incident.

Tech Engine can help implement managed AI agents that integrate with existing systems in a private Australian-hosted environment, with defined permissions, audit trails and human approval. To review your AI governance controls and supporting cyber security, contact sales@techengine.au or call 1300 088 324.