← Back to Blog

The AI Governance Challenge for Australian Agencies

For Australian government agencies and regulated enterprises, deploying generative AI is no longer a question of "if" but "how." The potential for efficiency gains is immense, but so are the risks. When dealing with citizen data, classified information, or critical infrastructure, a generic "AI wrapper" is insufficient. Deployments must align with the Australian Government Information Security Manual (ISM) and the Protective Security Policy Framework (PSPF) [1].

This means any AI system processing sensitive information must undergo an Information Security Registered Assessors Program (IRAP) assessment to operate at the PROTECTED level. However, achieving IRAP compliance for an AI system introduces unique architectural challenges that traditional SaaS applications do not face.

Why Generic AI Wrappers Fail IRAP Assessments

Many organisations attempt to build a simple user interface over an external API (like OpenAI or Anthropic) and assume that if the underlying cloud provider is IRAP assessed, their application inherits that compliance. This is a fundamental misunderstanding of cloud security [2].

An IRAP assessment evaluates the entire system boundary. A generic wrapper typically fails on three critical ISM controls:

The 4 Layers of the AI Shared Responsibility Model (SRM)

To architect an IRAP-ready deployment, you must first understand the Shared Responsibility Model (SRM) for AI. At Cetus AI, we map security and governance controls across four distinct layers. For each control, the SRM specifies whether it is the customer's responsibility, Cetus AI's responsibility, or a shared responsibility [4].

1. Infrastructure & Network

This foundational layer covers the physical security of data centres, network perimeter defences, and base compute isolation. If you deploy via Cetus AI's Platform BYOC (Bring Your Own Cloud), you leverage the existing IRAP PROTECTED status of your Azure or AWS tenancy. If you choose our SaaS Control/Gateway, Cetus AI manages the Australian-region data residency and network isolation.

2. Platform & Runtime

This is where the AI gateway operates. Responsibilities here include TLS 1.2+ encryption in transit, AES-256 encryption at rest, and the execution of the gateway logic itself. The platform must ensure that API keys are validated using SHA-256 hashing and that webhooks are signed with HMAC-SHA256 [5].

3. Data & Identity

This layer governs who can access the system and what data they can see. It involves integrating with your existing Identity Provider (IdP) via SAML/OIDC. Crucially, this is where inline PII redaction occurs—automatically stripping sensitive data from prompts before they leave your defined perimeter.

4. Policy & Compliance

The top layer involves defining the acceptable use policies, configuring the redaction rules, and maintaining the immutable audit logs. While the platform provides the mechanism for logging, the customer is responsible for defining the policies that align with their specific PSPF obligations.

"IRAP compliance is not a certificate you buy; it is an operational state you maintain. The architecture must enforce policy by default, making it mathematically impossible to bypass the governance layer."

Architecting with Songlines Gateway

To meet these stringent requirements, the architecture must place an enforcement mechanism between the user and the AI model. This is the role of the Songlines Gateway.

When a user submits a prompt, it does not go directly to the LLM. Instead, it is routed through the Gateway, where the following sequence occurs:

  1. Identity Verification: The user's session is validated against the IdP, and their RBAC permissions are checked.
  2. Policy Evaluation: The prompt is scanned against configured organisational policies (e.g., blocking queries related to restricted topics).
  3. Data Redaction: The payload is scanned for PII (names, Medicare numbers, financial data). Any identified PII is redacted or masked.
  4. Audit Logging: The original prompt, the redacted prompt, user ID, and timestamp are written to an immutable audit log.
  5. Model Routing: The safe, redacted prompt is forwarded to the appropriate model (e.g., a sovereign-hosted instance of Llama 3 or an Azure OpenAI endpoint).
  6. Response Logging: The model's response is received, logged, and returned to the user.

Why "IRAP-Ready" is the Critical First Step

An IRAP assessment is conducted on a specific, deployed system within a specific environment. Therefore, a vendor cannot sell you an "IRAP certified" SaaS product off the shelf. They can only provide an "IRAP-assessed" or "IRAP-ready" platform [6].

An IRAP-ready platform, like Cetus AI, provides a comprehensive Compliance Evidence Package. This package maps every feature of the platform directly to the relevant ISM controls. When your agency engages an IRAP assessor, this documentation drastically reduces the time, cost, and friction of the assessment process, as the technical controls are already proven and documented.

Conclusion

Deploying AI in the Australian government sector requires moving beyond experimental wrappers to enterprise-grade, defensible architectures. By implementing an inline control layer like Songlines Gateway and adhering to a clear Shared Responsibility Model, agencies can harness the power of generative AI while maintaining strict alignment with the ISM and PSPF.


References

[1] Australian Government, "Protective Security Policy Framework (PSPF)," Attorney-General's Department, 2026.
[2] Kiteworks, "IRAP Compliance | Australian Cybersecurity Standard," Kiteworks, 2026.
[3] Australian Signals Directorate, "Information Security Manual (ISM)," ASD, 2026.
[4] Cetus AI, "Sovereign AI: A Reference Architecture for Australian Government," Cetus AI Labs, Q4 2025.
[5] Microsoft, "Australian Government Information Security Registered Assessors Program (IRAP)," Microsoft Learn, Apr 2026.
[6] UiPath, "IRAP Certification for Australian Government Security," UiPath Trust and Security, 2026.