Most cloud breaches are not the result of an exotic zero-day. They start with an over-permissioned role, a forgotten access key, or a service account nobody owns. As Australian enterprises push more workloads into AWS and Azure — often both at once — identity has quietly become the real security perimeter. Getting cloud IAM best practices right is now the single highest-leverage thing most organisations can do to reduce risk without slowing delivery.

This guide walks through the practices that matter most for AWS and Azure, with an Australian regulatory lens (APRA CPS 234, the ACSC Essential Eight) and the operational reality of running identity at scale across multiple clouds.

Why cloud IAM is different from on-premises identity

On-premises identity grew up around a network boundary: get inside the firewall and Active Directory largely decided what you could reach. In the cloud that boundary is gone. Every API call to AWS or Azure is authenticated and authorised individually, and a single misconfigured policy can expose storage, compute, or an entire management plane to the public internet.

Two consequences follow. First, the blast radius of a bad permission is larger and faster to exploit. Second, identity is now programmable — which cuts both ways. The same APIs that let an attacker escalate privileges let you codify, review, and continuously test access. The enterprises that win treat IAM as code, not as a console clicking exercise.

Core cloud IAM best practices for AWS and Azure

1. Enforce least privilege — then keep proving it

Least privilege is easy to say and hard to sustain. Permissions accrete: someone needs write access for a migration, it never gets removed, and six months later that role is a liability. The practical discipline is to grant narrowly and review continuously.

• AWS: Use IAM Access Analyzer to generate policies from actual CloudTrail activity, and to flag resources shared outside your account. Prefer permission boundaries and Service Control Policies (SCPs) at the AWS Organizations level to cap what any account can do, regardless of local policy.
• Azure: Lean on built-in Azure RBAC roles before writing custom ones, scope assignments to the narrowest resource group or resource, and use Azure AD (Entra ID) access reviews to expire standing access that is no longer justified.

The goal is not a one-off cleanup but a repeatable loop: grant, monitor real usage, right-size, and re-review on a schedule.

2. Eliminate long-lived credentials

Static access keys are the credential most likely to end up in a public code repository, a laptop, or a CI log. Wherever possible, replace them with short-lived, federated credentials.

• For human access, federate through your identity provider with SSO rather than issuing IAM users. In AWS, IAM Identity Center (formerly AWS SSO) is the default; in Azure, Entra ID already is your directory.
• For workloads, use IAM roles for service accounts, workload identity federation, and Azure managed identities so machines authenticate without a stored secret at all.
• For CI/CD pipelines, use OpenID Connect federation (for example, GitHub Actions to AWS or Azure) instead of storing keys in the pipeline.

3. Make MFA and phishing-resistant auth non-negotiable

Multi-factor authentication on every human identity — especially privileged and break-glass accounts — is the baseline the Essential Eight explicitly calls for. Push beyond SMS and app codes toward phishing-resistant methods (FIDO2 security keys, passkeys) for administrators. In Azure, enforce this with Conditional Access; in AWS, require MFA in your identity provider and through IAM policy conditions for sensitive actions.

4. Separate privileged access from everyday access

Administrators should not carry standing high-privilege rights. Just-in-time elevation limits the window an attacker can abuse. Azure AD Privileged Identity Management (PIM) lets you grant time-bound, approval-gated activation of privileged roles; on AWS, achieve the equivalent with temporary role assumption, session policies, and approval workflows. This is where cloud IAM and dedicated privileged access controls meet — a topic we cover in depth in our guide to privileged access management.

5. Centralise identity across both clouds

Running AWS and Azure with two disconnected identity stores doubles the places a joiner-mover-leaver process can fail. Federate both to a single authoritative identity provider so that deprovisioning one account removes access everywhere. This is also the foundation for consistent logging, consistent policy, and a single access review rather than several.

6. Log everything and actually watch it

Enable AWS CloudTrail across all regions and accounts, and Azure AD sign-in and audit logs, then ship them to a central store you monitor. The signal that matters most: unusual privilege escalation, new access key creation, disabled logging, and sign-ins from unexpected locations. Detection is not optional — CPS 234 expects APRA-regulated entities to detect and respond to information security incidents in a timely way, and identity logs are where the earliest signals appear.

Governance: the practice that ties it together

Tooling gets you started; governance keeps you safe. Every access grant should trace back to a role or a request, every privileged account should have a named owner, and every quarter you should be able to answer “who can touch production, and why?” without a fire drill. This is the domain of identity governance — automated joiner-mover-leaver, periodic certification, and segregation-of-duties enforcement. For regulated Australian organisations, we explore this further in identity governance and administration for regulated industries.

Cloud IAM done well is not a product you buy once. It is an operating model: least privilege enforced as code, credentials that expire by default, privileged access granted just in time, and a governance layer that continuously proves the whole thing is still true.

Meeting Australian regulatory expectations

For AU enterprises, two frameworks anchor the conversation. APRA CPS 234 requires regulated entities to maintain information security capability proportionate to threats, to clearly define information security roles and responsibilities, and to test controls — identity controls very much included. The ACSC Essential Eight calls out MFA and restricting administrative privileges as core mitigations. Mature cloud IAM is, in practice, how you satisfy large parts of both. Building the evidence trail as you go — access reviews, logs, policy-as-code history — turns your next audit from a scramble into an export.

Where to start

If you are early in the journey, sequence it: federate identity to a single provider, enforce MFA everywhere, kill long-lived keys, then layer on least-privilege tuning and just-in-time privileged access. If you are further along, the highest-value move is usually continuous verification — turning point-in-time cleanups into automated reviews and policy-as-code guardrails.

Delivery Centric helps Australian and APAC enterprises design and operate cloud IAM across AWS and Azure — from identity federation and least-privilege architecture to privileged access and governance that stands up to APRA scrutiny. If you are scaling identity across multiple clouds and want it done once, properly, talk to our team. We are also growing our identity and cloud practice if you would rather build this from the inside.

Build vs Buy: A Practical Guide to Adopting Agentic AI in Your Enterprise

Almost every enterprise leader has now seen what agentic AI can do — software agents that plan a sequence of steps, call the systems they need, and carry a piece of work to completion with a human in the loop where it matters. The harder question isn’t whether to adopt it, but how. The enterprise AI build vs buy decision — build an agentic capability in-house, buy a packaged product, or partner to deliver something in between — will shape your cost, your speed to value, and how much control you keep over a technology that touches your core processes.

This guide breaks the decision down the way we approach it with clients across Australia and APAC: not as a religious debate, but as a set of trade-offs you can reason about against a specific business problem.

Start with the problem, not the platform

The most expensive agentic AI programmes are the ones that start with a tool and go looking for a use case. Before you weigh build against buy, get specific about the problem you’re solving and what “good” looks like:

• What manual or slow process is costing you? Claims handling, invoice matching, customer onboarding, IT support triage, procurement approvals — name the workflow and roughly what it costs in hours or delay.
• Which systems does the work touch? An agent is only as useful as the systems it can act on. A workflow that spans a legacy core, a CRM and three spreadsheets is a very different build than one that lives inside a single SaaS product.
• What’s the tolerance for error? A drafting assistant that a human always reviews carries far less risk than an agent that moves money or updates a system of record autonomously.

Once the problem is concrete, the build-versus-buy trade-offs become much easier to see, because you’re comparing options against a real target rather than a demo.

The enterprise AI build vs buy trade-offs

Buy: packaged and embedded agents

“Buy” usually means one of two things: a standalone agentic product, or agentic features embedded in software you already run (your ERP, service desk, CRM or contact-centre platform). The appeal is obvious — speed and a lower barrier to entry. You get a supported product, a roadmap someone else funds, and you avoid standing up AI and platform engineering talent you may not have.

Buying works best when the problem is common and well understood — summarising documents, drafting responses, answering questions over a knowledge base, or automating a workflow that sits neatly inside one vendor’s ecosystem. The limits show up when your process is differentiated, spans multiple systems the vendor doesn’t reach, or when your data and IP are the very things that make the capability valuable. You also inherit the vendor’s pace, pricing model and guardrails, and switching later can be difficult if you want to move.

Build: a bespoke agentic capability

“Build” means assembling your own solution on foundation models and an orchestration framework, integrated with your systems and governed by your own controls. It costs more up front and demands real engineering discipline — but it’s the right call when the workflow is a competitive differentiator, when agents must reach across systems no single product covers, or when data residency, sovereignty and control are non-negotiable.

The mistake teams make is assuming “build” means building the model. It almost never does. You’re building the orchestration, the integrations, the evaluation harness and the guardrails around commercially available models. That’s a systems-integration and software-engineering problem far more than a data-science one — which is good news, because it’s a discipline most enterprises can resource or partner for.

Partner: the pragmatic middle

In practice, most enterprises land in the middle: buy the commodity layers (foundation models, vector stores, cloud infrastructure) and build the thin, high-value layer that’s specific to your business — the orchestration logic, the integrations and the guardrails. A delivery partner can stand this up quickly, transfer the capability to your team, and avoid the two classic failure modes: a shelfware product that never fits, or an over-engineered in-house platform that takes a year to reach production. Our Agentic AI practice is built around exactly this pattern — accelerating the build where it matters while reusing everything that’s already a commodity.

A decision framework you can actually use

When we help clients make the call, five factors do most of the work:

1. Differentiation. Is this workflow a source of competitive advantage, or just table stakes? Differentiators lean build; commodities lean buy.
2. Integration depth. The more systems an agent must read from and act on — especially legacy ones — the more a packaged product will struggle, and the more a bespoke build earns its cost.
3. Data sensitivity and sovereignty. Regulated data, strict residency requirements, or IP you can’t hand to a third party push you toward build or a tightly controlled private deployment.
4. Time to value. If you need a result this quarter and the problem is common, buy or embed. If the payoff is large and durable, a build pays back.
5. Total cost over three years. Compare per-seat or per-transaction licensing at scale against a one-off build plus run costs. Buy is cheaper to start and can get expensive at volume; build is the reverse.

No single factor decides it. But scoring a specific workflow against all five turns a vague “should we build or buy?” into a defensible recommendation — and often reveals that different parts of the same programme want different answers.

What good adoption looks like, whichever way you go

The build-versus-buy choice matters less than the discipline you bring to it. The enterprises getting real value from agentic AI tend to do the same handful of things:

• Start narrow and prove it. One workflow, a clear baseline, and a measurable outcome beats a broad “AI transformation” every time.
• Keep a human in the loop where it counts. Match the level of autonomy to the cost of a mistake, and earn more autonomy as evidence accumulates.
• Instrument everything. Log what agents do, evaluate quality continuously, and make it easy to intervene. Governance and guardrails aren’t a bolt-on — they’re what makes production adoption safe.
• Plan for the run, not just the launch. Models change, data drifts and processes evolve. Someone has to own the capability after go-live.

Cloud foundations matter here too: agentic workloads need scalable, well-governed infrastructure to run reliably and cost-effectively, which is why adoption and cloud strategy tend to move together.

Making the call

There’s no universal answer to enterprise AI build vs buy — only the right answer for a specific problem, weighed against differentiation, integration depth, data sensitivity, time to value and cost at scale. Buy the commodity, build the difference, and bring engineering discipline to whichever path you take. For Australian and APAC enterprises in particular, keeping data control and integration with legacy systems front of mind often tilts the balance toward a bespoke or hybrid build — done pragmatically, not from scratch.

If you’re weighing the options for a specific workflow, Delivery Centric can help you score it and stand up a working pilot quickly. Explore our Agentic AI capabilities, read how these ideas play out in a regulated setting in Agentic AI in Banking, or join the team building it.

Identity Governance and Administration (IGA) in Regulated Industries

Identity governance has moved from a back-office housekeeping task to a board-level obligation for Australian enterprises in banking, insurance, health and government. Regulators now expect organisations to prove — not just assert — that the right people have the right access to the right systems, and that every entitlement can be traced, justified and revoked. For regulated industries, a mature identity governance and administration (IGA) programme is the difference between passing an audit cleanly and scrambling to explain why a departed contractor still had access to a production database six months later.

This guide explains what IGA actually delivers, why regulated sectors in Australia and across APAC face particular pressure, and how to build a programme that satisfies auditors without grinding the business to a halt.

What identity governance and administration actually covers

IGA is the discipline of managing digital identities and their access rights across their entire lifecycle — from the day someone joins to the day they leave, and every role change in between. It sits above the day-to-day mechanics of authentication and single sign-on, answering a harder set of questions:

• Who has access to what, and can you produce that answer on demand?
• Should they still have it? Access granted for a project two years ago rarely gets cleaned up on its own.
• Who approved it, and is that approval recorded in a way an auditor will accept?
• Are risky combinations blocked? Separation-of-duties conflicts — such as one person both raising and approving a payment — need to be detected before they become a fraud finding.

A working IGA capability typically combines automated joiner-mover-leaver provisioning, periodic access certifications (or “recertifications”), role-based access models, segregation-of-duties controls, and a complete audit trail. Done well, it reduces the standing access that attackers exploit and shrinks the manual review burden that quietly consumes IT and risk teams.

IGA vs IAM vs PAM — where the lines sit

These acronyms overlap and get used loosely. Identity and access management (IAM) is the broad umbrella covering authentication and access. Privileged access management (PAM) focuses specifically on high-risk administrative accounts. IGA is the governance layer that decides and evidences who should have access in the first place. Most regulated enterprises need all three working together. If you’re untangling the first two, our explainer on IAM vs PAM is a useful companion read.

Why regulated industries in Australia feel the pressure

Regulated sectors carry obligations that make weak identity governance genuinely expensive. In Australian financial services, APRA’s CPS 234 requires regulated entities to maintain information security capabilities commensurate with the threats they face — and access management is a recurring theme in the control expectations and in post-incident reviews. Health and government bodies handling sensitive personal information sit under the Privacy Act and, increasingly, sector-specific data-handling rules. Across APAC, comparable regimes apply: Singapore’s MAS Technology Risk Management guidelines and New Zealand’s evolving privacy expectations push in the same direction.

The common thread is evidence. It is no longer enough to have a policy that says access is reviewed. Auditors want to see the review happened, on a defined cadence, with named approvers and documented outcomes. Organisations that manage certifications in spreadsheets typically discover — usually mid-audit — that the evidence is incomplete, stale, or impossible to reconcile against the live directory.

The cost of “access sprawl”

In large enterprises, entitlements accumulate faster than anyone removes them. People change roles and keep old access “just in case”. Contractors onboard quickly and offboard slowly. Service accounts multiply. The result is access sprawl: a growing population of standing privileges that expands the attack surface and makes every certification cycle more painful. Regulated industries feel this acutely because the systems in question — core banking, policy administration, patient records — are exactly the ones regulators scrutinise.

Building an IGA programme that auditors trust

A durable identity governance capability in a regulated Australian enterprise usually comes together in stages rather than a single big-bang rollout.

1. Establish an authoritative source of identity

Governance is only as good as the data underneath it. The HR system (for employees) and a contractor register (for non-employees) should drive identity lifecycle events. When a leaver is marked terminated in HR, downstream access should be revoked automatically — not left to a manual ticket that may never be raised.

2. Automate joiner-mover-leaver provisioning

Automated provisioning removes the two biggest sources of audit findings: access that is granted too broadly on day one, and access that lingers after departure or role change. Birthright access tied to role, with everything beyond that requested and approved, gives you both speed and control.

3. Model access with roles — but stay pragmatic

Role-based access control makes certifications tractable, because reviewers approve a coherent role rather than hundreds of individual entitlements. The trap is over-engineering the role model until it becomes unmaintainable. Start with high-value, high-population roles, and accept that some access will always be handled as exceptions.

4. Run risk-based access certifications

Certifying everything on the same cycle wastes reviewer attention on low-risk access and rushes the review of dangerous access. Prioritise privileged accounts, access to regulated data, and separation-of-duties-sensitive entitlements for more frequent, more careful review. Rubber-stamping is the enemy — a certification that approves 100% of access in seconds is a finding waiting to happen.

5. Capture the evidence automatically

Every grant, approval, certification decision and revocation should be logged in a form you can hand to an auditor without a week of preparation. This is where a purpose-built IGA platform earns its keep over manual processes.

Common pitfalls to avoid

• Treating IGA as a tooling project. The technology is the easy part. The hard part is defining roles, owners and approval workflows with the business — which is where most programmes stall.
• Boiling the ocean. Attempting to onboard every application at once usually collapses under its own weight. Sequence by risk and regulatory exposure.
• Ignoring non-human identities. Service accounts, API keys and automation credentials often outnumber human users and are frequently the least governed.
• Certification fatigue. If reviewers are drowning, they rubber-stamp. Reduce the volume with better role models and risk-based scoping so the reviews that matter get real attention.

Where Delivery Centric fits

Delivery Centric helps Australian and APAC enterprises design and deliver identity governance programmes that stand up to regulatory scrutiny — from establishing authoritative identity sources and automating the joiner-mover-leaver lifecycle, to building role models and risk-based certification processes that satisfy APRA, MAS and privacy obligations without exhausting the business. Our consultants work across banking, insurance, health and government, and pair governance design with the wider identity and cyber security services that regulated organisations depend on. For teams weighing regulatory readiness specifically, our APRA CPS 234 compliance checklist is a practical starting point.

If you’re scaling an identity practice and want to work on this kind of engagement, we’re hiring — see our careers page.

Ready to strengthen your identity governance? Talk to Delivery Centric about an IGA assessment tailored to your regulatory environment — we’ll map where your access risk really sits and give you a sequenced roadmap to close it. Get in touch to start the conversation.

Agentic AI in Banking: Practical Use Cases for Financial Services

Banks have spent the last decade automating tasks. The next decade is about automating decisions and workflows end to end. That shift is what agentic AI in banking makes possible: software agents that don’t just answer a question or classify a document, but plan a sequence of steps, call the systems they need, and carry a piece of work to completion with a human in the loop where it matters. For Australian and APAC financial institutions weighed down by legacy cores, manual back-office processes and rising cost-to-income pressure, this is less a science project and more an operating-model question.

At Delivery Centric we build enterprise applications with agentic AI across whatever a customer actually needs — the banking use cases below are where we see the clearest, near-term return.

What “agentic” actually means for a bank

A traditional model responds to a single prompt. An agent is given a goal, breaks it into steps, and uses tools — your core banking system, a document store, a fraud engine, an email gateway — to reach that goal. It can reason about what to do next, retry when a step fails, and escalate to a person when it hits a threshold or an exception it isn’t allowed to clear.

For a bank, three properties make this different from the RPA and chatbot wave that came before:

• It handles variation. Rules-based automation breaks the moment a document, a customer request or a data field looks slightly different. Agents tolerate messiness because they reason over context rather than matching a fixed template.
• It orchestrates across systems. Most banking work spans five or six applications. An agent can stitch those together without a fresh point-to-point integration for every path.
• It keeps an audit trail. A well-built agent logs every step, tool call and decision — which is exactly what a regulated institution needs to prove what happened and why.

High-value use cases in financial services

1. Customer onboarding and KYC remediation

Onboarding is where growth and compliance collide. An agent can collect and validate identity documents, cross-check them against sanctions and PEP lists, flag mismatches, request missing information from the customer, and prepare a clean case for a compliance officer to approve. In KYC remediation — the periodic re-verification of an existing book — the same pattern clears the bulk of low-risk records automatically and routes only genuine exceptions to a human. That turns a backlog of tens of thousands of files into a triaged queue.

2. Loan and credit processing

A credit decision touches application data, bank statements, serviceability calculations, policy rules and supporting documents. An agent can assemble the file, extract and reconcile figures from statements and payslips, run them against lending policy, and produce a structured recommendation with its reasoning attached. The banker still decides — but they start from a complete, checked package instead of a shoebox of PDFs.

3. Fraud and dispute handling

When a transaction is disputed, someone has to gather the transaction history, pull the merchant details, check prior patterns, apply scheme rules and draft a response within tight chargeback windows. Agents compress that from hours to minutes by doing the gathering and first-pass analysis, leaving the analyst to confirm the call on the cases that are genuinely borderline.

4. Back-office reconciliation and exceptions

Reconciliations, payment repairs, failed settlements and nostro breaks are the quiet cost centre of every bank. These are ideal agentic workloads: high volume, rule-heavy but variable, and today handled by people copying data between screens. An agent investigates the break, proposes the fix, and either applies it within an approved limit or escalates with a full explanation.

5. Contact-centre assist and complaint handling

Beyond the front-end chatbot, an agent working alongside a contact-centre officer can retrieve the customer’s full context, draft the response, complete the follow-up actions across systems, and log the interaction — including the regulatory clock on complaints. The officer stays in control; the drudgery disappears.

Why banking is a good fit — and where the risk sits

Banking has three things that make agentic AI unusually valuable: enormous volumes of structured and semi-structured work, deep process documentation (policies, procedures, controls) that agents can be grounded in, and a workforce spending too much time on manual handling. But financial services also carries the tightest constraints, and that is exactly the point where implementations succeed or fail.

The risks are real and manageable: hallucinated outputs on a customer file, an agent acting outside its authority, data leaving a controlled boundary, and the difficulty of explaining an automated decision to a regulator. None of these are reasons to wait; they are design requirements. Every banking agent should run with scoped permissions, hard action limits, mandatory human approval on anything material, full logging, and grounding in the bank’s own approved knowledge rather than open-ended generation. We treat those guardrails as part of the build, not an afterthought — the same discipline we set out in our guide to agentic AI governance, guardrails and control.

The Australian and APAC context

For Australian institutions, agentic workloads have to sit comfortably inside APRA’s prudential expectations — including CPS 230 operational-risk and CPS 234 information-security obligations — with clear ownership, data residency and the ability to demonstrate control. Across APAC, Singapore’s MAS and other regulators are moving in the same direction: encouraging AI adoption while demanding governance and accountability. The upshot is that banks who build agents on a controlled, auditable foundation now will be the ones who can scale them later, rather than retrofitting compliance onto a proof of concept that was never designed for it.

How to start without boiling the ocean

The banks getting value aren’t rolling out an “AI transformation.” They pick one painful, high-volume process with a clear success measure — say, KYC remediation throughput or reconciliation exception rates — and build a single agent for it end to end, with humans firmly in the loop. Once that agent is proven, trusted and governed, the pattern and the platform extend to the next process. This is where connecting agents to legacy cores and surrounding systems matters most, and where our enterprise integration and AI capabilities do the heavy lifting.

Agentic AI in banking is not about replacing bankers. It’s about giving them clean, complete, checked work and taking back the hours lost to shuffling data between systems. The institutions that win will be the ones that treat it as an operating-model change delivered under proper control — not a gadget bolted onto the edge.

Ready to identify the right first use case? Talk to Delivery Centric about scoping an agentic AI pilot for your bank — or, if you’re looking to build a career in enterprise AI and financial services delivery, see our current openings.

Privileged Access Management in Australia: Stopping Breaches Before They Start

Almost every serious breach has the same fingerprint: an attacker gets hold of a credential that can do too much. A privileged account — a domain admin, a root login, a service account wired into production, a cloud key with god-mode permissions — is the difference between an intruder who is stuck at the front door and one who owns the building. That is why privileged access management has moved from a nice-to-have to a board-level control for Australian enterprises. Get it right and you shrink the blast radius of an attack dramatically. Get it wrong and a single phished password becomes a full-scale incident.

This guide explains what privileged access management (PAM) actually does, why it matters for organisations operating under APRA, the Essential Eight and the Privacy Act, and how to roll it out without grinding your delivery teams to a halt.

What privileged access management really means

Privileged access management is the discipline of controlling, monitoring and securing accounts that hold elevated permissions. Where identity and access management (IAM) governs the everyday identities of your whole workforce, PAM zeroes in on the small set of accounts that can change configurations, read sensitive data in bulk, or bring systems down. If you want the fuller distinction, we cover it in IAM vs PAM: what’s the difference and why Australian enterprises need both.

A mature PAM capability typically delivers four things:

• A credential vault. Privileged passwords, SSH keys and API secrets are stored centrally, rotated automatically, and never known to the human using them.
• Just-in-time access. Instead of standing admin rights that sit dormant and dangerous, users request elevation for a defined task and window, then the access expires.
• Session isolation and recording. Privileged sessions run through a broker that records what happened, so you have an audit trail and can terminate a suspicious session in real time.
• Least privilege enforcement. Accounts — human and machine — get only the permissions they genuinely need, and nothing more.

Why privileged access is the attacker’s favourite target

Credential abuse is not a fringe technique; it is the mainstream. Attackers phish a user, harvest a token, then move laterally hunting for the accounts that unlock everything else. Ransomware crews in particular follow a predictable path: initial foothold, privilege escalation, then domain-wide encryption. Every step after the first depends on privileged access they were never supposed to have.

Three trends have made the problem worse for Australian organisations:

• Cloud sprawl. Every AWS, Azure and Google Cloud tenancy multiplies the number of privileged roles, access keys and service principals — often created quickly during a project and forgotten.
• Machine identities. Service accounts, CI/CD pipelines and automation now outnumber human users, and they frequently run with excessive, unrotated credentials.
• Hybrid estates. Legacy on-premises systems sit alongside SaaS and cloud-native workloads, and privileged access has to be governed consistently across all of them.

The Australian compliance angle

For regulated industries, privileged access management is increasingly something you have to be able to evidence, not just assert. A few of the frameworks that push it to the top of the list:

• APRA CPS 234. Banks, insurers and superannuation funds must maintain information security capability proportionate to the threat, including controls over who can access critical assets. Privileged access sits squarely inside that expectation — see our CPS 234 identity compliance checklist for the detail.
• The Essential Eight. The ACSC’s “restrict administrative privileges” strategy is, in practice, a PAM mandate: limit admin rights, validate them regularly, and separate privileged accounts from day-to-day use.
• The Privacy Act and the Notifiable Data Breaches scheme. Limiting who can access personal information in bulk is a core way to reduce both the likelihood and the reportable impact of a breach.

The common thread is that regulators want to see least privilege enforced and audited — and PAM is how you demonstrate it.

Privileged access management and Zero Trust

PAM is not a standalone island; it is one of the load-bearing walls of a Zero Trust architecture. Zero Trust assumes no user, device or session is inherently trustworthy, and it verifies every access request against context. Privileged access is where that principle earns its keep: an admin action should require strong authentication, be granted just in time, be scoped to a single task, and be recorded end to end. If you are building towards Zero Trust, our practical Zero Trust roadmap for Australian enterprises shows where PAM fits alongside identity, network and device controls.

How to roll out PAM without breaking delivery

The biggest PAM failures are not technical — they are adoption failures. Lock things down too hard, too fast, and engineers route around the controls. A staged approach works far better.

1. Discover and inventory privileged accounts

You cannot protect what you cannot see. Start by discovering every privileged account across Active Directory, cloud tenancies, databases, network devices and applications — including the service accounts and orphaned admin logins nobody remembers creating. Almost every organisation is surprised by how many it finds.

2. Vault and rotate the crown jewels first

Prioritise the accounts that would cause the most damage: domain admins, cloud root and break-glass accounts, and the credentials embedded in critical production systems. Bring these into a vault, remove hard-coded passwords, and enable automatic rotation.

3. Move to just-in-time access

Eliminate standing privilege wherever you can. Shift admins to requesting elevation for a defined task and time window. This single change removes the dormant, always-on accounts that attackers love.

4. Record sessions and wire in monitoring

Route privileged sessions through a broker that records activity and feeds your SIEM. Alert on anomalies — access at odd hours, from new locations, or to systems a user has never touched — so you can respond while an incident is still small.

5. Extend to machine and cloud identities

Once human privileged access is under control, turn to service accounts, secrets in CI/CD pipelines, and cloud entitlements. These are now the fastest-growing category of privileged risk and the one most often left unmanaged.

Common pitfalls to avoid

• Treating PAM as a product install. The tool is maybe 30% of the outcome; the operating model, workflows and adoption are the rest.
• Ignoring break-glass. You need emergency access that is tightly controlled and heavily audited — not a sticky note with the root password.
• Forgetting the developers. If PAM adds friction to legitimate work without an easy path, engineers will build workarounds that reopen the very gaps you closed.
• Stopping at on-prem. Cloud entitlements and machine identities are where the exposure is growing fastest.

Where Delivery Centric fits

Delivery Centric helps Australian and APAC enterprises design and deliver privileged access management as part of a broader identity and Zero Trust strategy — from discovery and vaulting through to just-in-time access, session monitoring and cloud entitlement management. Our consultants work across banking, insurance, government and telco environments where CPS 234, the Essential Eight and the Privacy Act set the bar, and we focus on rollouts that stick because delivery teams can actually live with them. Explore our cyber security services to see how we approach it.

If securing privileged access is on your roadmap, talk to our team about a PAM readiness assessment — or, if you would rather help build these capabilities, take a look at the roles on our careers page.

As enterprise adoption of Artificial Intelligence moves rapidly from exploratory chat interfaces to autonomous agents, a fundamental shift in software architecture is underway. Unlike static chatbots that simply retrieve information or respond to structured prompts, agentic systems possess the ability to plan multi-step workflows, call external APIs, query databases, and execute actions with minimal human intervention. While this autonomous capacity unlocks unprecedented levels of operational efficiency, it also introduces novel risks that legacy software governance frameworks are entirely unequipped to manage. For APAC and global technology leaders, implementing robust enterprise-wide control structures is no longer an optional security exercise; it is a critical prerequisite for unlocking the commercial potential of modern AI applications.

To safely deploy autonomous workflows, modern organisations must establish a comprehensive framework for agentic ai governance. This requires moving beyond traditional perimeter-security models and static software testing, adopting instead a dynamic approach centered on runtime guardrails, deterministic execution limits, and clear operational oversight. By building safety directly into the agentic lifecycle, enterprises can confidently transition autonomous systems from sandboxed pilots into mission-critical production environments.

The Shift to Agentic Autonomy: A New Governance Paradigm

Traditional enterprise software is deterministic: developers write explicit code pathways, and the software executes those exact steps every single time. Governance in this environment consists of static code reviews, pre-deployment security scanning, and role-based access controls. Agentic AI, however, operates probabilistically. Guided by large language models (LLMs), an autonomous agent dynamically plans its own path to achieve a high-level goal, choosing which tools to call and what actions to execute based on real-time outputs.

This dynamic planning capability creates a massive governance gap. If an agent is tasked with resolving a customer invoice discrepancy, it might decide to query an ERP database, compare historical contract terms, calculate a dynamic discount, and email a settlement offer to the customer. While the efficiency gains are profound, the lack of static execution paths means enterprises must govern the boundaries of what the agent can do, rather than trying to predict and hard-code every individual action. This shifts the focus of enterprise IT teams from traditional access controls to real-time, context-aware guardrails.

Core Pillars of an Agentic AI Governance Framework

A reliable enterprise application built on agentic architectures requires a governance model structured around three core operational pillars: runtime safety guardrails, deterministic transaction limits, and continuous auditability.

1. Runtime Safety Guardrails and Input/Output Sanitisation

Runtime guardrails act as an active, real-time safety layer wrapped around the core agent. These guardrails monitor all incoming data (user prompts and tool outputs) and outgoing data (agent-generated responses and database queries) to intercept harmful, non-compliant, or unexpected behavior before it reaches external systems.

• Prompt Injection Defence: Filtering out adversarial inputs that attempt to override the agent’s system instructions or hijack its execution paths.
• Data Loss Prevention (DLP): Scanning outgoing agent responses to ensure sensitive customer data, proprietary IP, or personally identifiable information (PII) is never leaked.
• Output Validation: Validating that agent-generated tool calls conform strictly to expected schemas (e.g., ensuring a database query generated by an agent does not contain destructive SQL commands like DROP TABLE).

2. Deterministic Transaction Limits and Tool Sandboxing

Because autonomous agents can initiate external transactions, they must operate under strict, deterministic constraints. Just as organizations do not give human employees unlimited spending limits or unfettered system access on day one, agentic systems must be carefully restricted:

• Financial and Execution Caps: Setting hard limits on the volume or value of transactions an agent can execute without explicit human approval. For example, a procurement agent might be permitted to auto-approve invoices up to $500, but any transaction above that threshold must trigger an automated approval workflow.
• API Rate Limiting and Token Budgets: Restricting the number of sequential tool calls or LLM tokens an agent can consume within a single execution loop. This prevents runaway agentic loops that could generate massive API bills or flood downstream systems with spam requests.
• Network and Workspace Isolation: Running the execution environment of the agent in a secure, sandboxed container, ensuring that any local file operations or command-line execution cannot compromise the underlying host system.

3. Continuous Auditability and ‘Human-in-the-Loop’ (HITL) Controls

A transparent audit trail is essential for compliance, debugging, and continuous improvement. Every decision, plan, execution step, and tool call made by an agent must be logged in a secure, tamper-proof system of record. These logs must record:

• The exact system prompt and model configuration used.
• The dynamic plan formulated by the agent at each step of the run.
• The specific input and output payloads for every tool execution.
• The exact human actions or approvals associated with the execution.

By coupling deep logging with a structured ‘Human-in-the-Loop’ workflow, organizations can scale the autonomy of their systems safely. Low-risk operations run fully autonomously, medium-risk actions trigger asynchronous notifications, and high-risk actions remain strictly gatekept by human decisions.

Integrating Agentic Governance into the Enterprise Software Lifecycle

Deploying agentic systems successfully requires close integration with your broader enterprise software lifecycle. Organizations should treat AI agents as dynamic software assets, managing them through rigorous testing, deployment, and monitoring practices. This lifecycle begins with establishing comprehensive testing suites that evaluate agents against a wide array of simulated edge cases, checking how they handle unexpected tool failures or corrupt inputs. Rather than relying solely on subjective manual reviews, teams can implement automated evaluators to score agent performance on accuracy, safety compliance, and alignment with corporate guidelines.

Once deployed, continuous monitoring is critical to detect performance drift or changes in user interaction patterns over time. This ongoing observability ensures that as models are updated or external system dependencies evolve, the agent maintains its operational integrity and remains firmly within established safety thresholds.

How Delivery Centric Helps Enterprises Scale AI Safely

At Delivery Centric, we specialise in helping organisations design, build, and deploy production-grade enterprise applications leveraging advanced Agentic AI architectures. We understand that technology is only half the equation—the real challenge lies in integrating autonomous capabilities into highly regulated, complex enterprise environments with robust governance, clear risk mitigations, and comprehensive security standards. Our teams work alongside APAC and global enterprise clients to architect custom LLM gateways, construct tailored guardrail systems, and build scalable Agentic workflows that drive measurable business impact while strictly preserving compliance and data sovereignty.

Whether you are modernising your legacy applications, automating complex back-office workflows, or building next-generation customer experience platforms, our end-to-end consulting and engineering capabilities ensure your systems are resilient, highly performant, and fully auditable from day one.

To learn more about how we can accelerate your business transformation, explore our Professional Services portfolio, read our previous insights on IAM vs PAM best practices, or find out how you can join our growing engineering team on our Careers Page.

Ready to Build Your Enterprise AI Strategy?

The transition from passive chatbots to active, autonomous agentic workflows is the defining technology shift of the decade. By implementing a proactive governance framework today, your enterprise can capture the massive competitive advantages of autonomous operations while completely neutralising the associated operational risks. Contact the team of technology consultants at Delivery Centric today to schedule an architectural workshop and map out a secure, compliant, and highly performant path forward for your enterprise AI initiatives.

APRA CPS 234 has been in force since 1 July 2019, and most Australian banks, insurers and superannuation funds long ago ticked the box that says “we are compliant”. The uncomfortable question, seven years on, is whether that box still reflects reality — because the standard is written in terms of outcomes and capability, not a fixed control list, and the environment it governs has changed enormously. Identity is where that gap shows up first. This article sets out a practical CPS 234 compliance checklist through an identity security lens: what the standard actually asks for, where identity controls typically fall short, and what evidence a board or an APRA reviewer will expect to see.

What CPS 234 requires — in plain terms

Prudential Standard CPS 234 Information Security applies to APRA-regulated entities: authorised deposit-taking institutions, general and life insurers, private health insurers, and RSE licensees. Its objective is straightforward — an entity must maintain information security capability commensurate with the size and extent of the threats it faces, so it can continue to operate soundly if an incident occurs.

Stripped of the legal drafting, the standard imposes a handful of obligations that matter operationally:

• Board accountability. The Board is ultimately responsible for the entity’s information security. Roles and responsibilities across the Board, senior management and governing bodies must be clearly defined.
• Information asset identification and classification by criticality and sensitivity — including assets managed by third parties.
• Controls commensurate with the threat, implemented to protect those assets, with the vulnerabilities and threats considered explicitly.
• Systematic testing and assurance of control effectiveness, with a testing programme whose frequency reflects the rate of change in the environment.
• Internal audit review of the design and operating effectiveness of information security controls, including those of third-party providers.
• Incident detection, response and notification — including notifying APRA no later than 72 hours after becoming aware of a material information security incident, and no later than 10 business days after identifying a material control weakness the entity does not expect to remediate in a timely manner.
• Third-party assurance where information assets are managed by a service provider.

Note the recurring word: commensurate. CPS 234 does not tell you which multi-factor authentication method to deploy. It asks you to demonstrate that your control set is proportionate to your risk, and that you have tested it well enough to know. That is a much harder standard to satisfy with a spreadsheet.

The CPS 234 identity security checklist

Identity is not named as a separate chapter in the standard, but it sits underneath almost every clause. Access is the control layer that determines whether an information asset is actually protected, and identity systems are themselves critical information assets. Work through the following.

1. Are your identity systems classified as critical information assets?

Directory services, single sign-on, the privileged access vault, the identity governance platform and the MFA service are not supporting infrastructure — they are the control plane for everything else. Many asset registers still classify them as internal IT tooling. If your identity provider is compromised, every downstream classification becomes theoretical. Classify accordingly, and make sure the register reflects the SaaS identity services you have adopted since the register was last reviewed.

2. Can you produce a complete, current inventory of privileged access?

This is the single most common evidence gap. Named administrators are usually well documented; what tends to be missing are service accounts, embedded credentials in scripts and pipelines, break-glass accounts, vendor support access, and standing cloud roles with entitlements nobody has reviewed. If you cannot answer “who and what holds privileged access to this asset today” within a working day, the underlying control cannot be said to be effective. A structured privileged access management capability exists precisely to make that answer available on demand.

3. Is access granted on entitlement, and removed on change?

Joiner-mover-leaver is where policy meets payroll. Leavers are typically handled well because they trigger an obvious event. Movers are not: someone transfers from operations to finance and accumulates both entitlement sets. Over a few years, this produces the privilege creep that turns a single compromised account into an enterprise-wide incident. Recertification campaigns are the standard answer, but they only work if reviewers are given meaningful context rather than a list of cryptic group names to rubber-stamp.

4. Are third-party and non-human identities inside the same control set?

CPS 234 explicitly extends to information assets managed by related parties and third parties. In practice, that means the managed service provider’s engineers, the offshore development team, the integration partner’s API credentials and the automation accounts running in your pipelines all sit within scope. Machine identities now routinely outnumber human ones in cloud estates, and they rarely pass through the same governance. APRA’s expectation is not that you own every control, but that you have assessed the provider’s capability and can evidence that assessment. The tightening of service provider expectations under CPS 230 Operational Risk Management has raised the bar here further.

5. Do you test identity controls, or only document them?

“Systematic testing” is a deliberate phrase. A policy stating that MFA is enforced is not evidence; a test result showing that authentication without a second factor was attempted and blocked — across every access path, including legacy protocols and emergency routes — is. The paths that fail testing are almost always the exceptions: the legacy application that could not support modern authentication, the VPN bypass created during a migration, the vendor account exempted “temporarily” in 2023.

6. Would your incident response plan survive an identity compromise?

Most response plans assume the identity system is available and trustworthy during the incident. If the directory itself is the compromised asset, how do you authenticate responders, revoke sessions at scale, or issue emergency credentials? Test that scenario specifically. It also sharpens the 72-hour notification clock: you cannot assess materiality without knowing which identities were affected and what they could reach, which brings you straight back to points 1 and 2.

7. Can internal audit form an independent view?

The standard requires internal audit to review design and operating effectiveness. That requires audit to have access to identity data and enough capability to interpret it. Where the identity function also produces the evidence and defines the tests, independence is weak. Sequencing an external assessment before your next internal audit cycle is a reasonable way to find the gaps on your own terms.

Where compliance programmes typically go wrong

Three patterns recur across Australian financial services engagements.

Point-in-time attestation. An assessment is completed, findings are remediated, and the artefacts age quietly for eighteen months while cloud migrations and new SaaS adoption change the estate underneath. CPS 234 asks for a capability that is maintained, not a project that was completed.

Treating identity as an IT deliverable. When the identity roadmap lives entirely inside infrastructure, business context — who should hold which entitlement and why — never reaches the control design. Recertification then becomes a compliance ritual instead of a risk decision. If the distinction between broad access governance and privileged control is unclear in your organisation, our explainer on IAM vs PAM and why Australian enterprises need both is a useful starting point.

Evidence that cannot be produced on demand. The remediation is genuine, but the proof is scattered across ticketing systems, vendor portals and email threads. Assurance work then costs more than the control itself. Design the evidence trail at the same time as the control — automated access reviews, exportable entitlement reports and logged approvals — rather than reconstructing it under review pressure.

Turning the checklist into a programme

The sequencing that works is unglamorous: establish the asset and access inventory first, because nothing downstream is credible without it; close privileged access gaps next, because that is where the material risk concentrates; then move to governance, recertification and automated evidence; and finally build testing into business-as-usual rather than treating it as an annual event. Aligning that roadmap with related obligations — the Essential Eight, CPS 230, and your own operational resilience commitments — avoids running three overlapping programmes with three sets of evidence.

Delivery Centric works with Australian banks, insurers and superannuation funds on exactly this problem, from enterprise identity design and implementation through to governance, privileged access and ongoing assurance. If you are approaching an internal audit cycle, an independent assessment, or a cloud migration that changes your control landscape, a focused gap review against CPS 234 is a sensible first step — and considerably cheaper than discovering the gap during an incident.

If you would rather build this capability in-house, we are also hiring identity and cyber security consultants across Australia and APAC — see our current openings. Otherwise, get in touch and we will talk through where your programme actually stands.

Agentic AI changes a foundational assumption in enterprise security: that the thing requesting access is either a human or a predictable, hard-coded service account. An agent is neither. It reasons, chains tools together, calls APIs you did not anticipate, and acts on behalf of a person who is not watching. For Australian enterprises already stretched by enterprise identity debt, this is the moment identity stops being a back-office control and becomes the operating layer for AI itself.

Why agentic AI breaks traditional IAM assumptions

Identity and access management was designed around two clean categories. Human identities get lifecycle management, MFA, and periodic access reviews. Machine identities — service accounts, API keys, certificates — get provisioned once and largely forgotten. Agentic AI collapses both categories into something new.

An agent behaves like a human: it makes decisions in the moment, interprets ambiguous instructions, and reaches for whatever tool solves the problem in front of it. But it authenticates like a machine: no browser, no push notification to approve, no second factor a person can respond to. It also operates at machine speed and machine scale. A misconfigured human account might cause damage over hours. A misconfigured agent with broad API scope can do it in seconds, repeatedly, across every system it can reach.

Three specific assumptions break:

• Static entitlement is safe. Traditional role-based access assumes the set of things an identity needs is knowable in advance. Agents discover what they need at runtime — that is the entire point of them.
• The authenticated principal is the accountable party. When an agent acts on behalf of a user, the credential presented is often the agent’s, not the person’s. Your audit trail records the wrong actor.
• Standing access is manageable. Long-lived tokens issued to agents are the new orphaned service account, except they are created faster and by more teams.

The agentic AI IAM control set

The good news is that this does not require an entirely new discipline. It requires applying identity fundamentals — the ones many organisations deferred for machine identities — with far more rigour. Four controls matter most.

1. Give every agent a first-class identity

Agents should be registered identities in your directory or identity provider, not credentials embedded in an application config. That means each agent has an owner, a business justification, a defined scope, a lifecycle, and an expiry. If an agent cannot be listed in an access review alongside human accounts, it is invisible — and invisible identities are how breaches start.

Practically, this means treating agent onboarding like joiner-mover-leaver. When an agent’s use case is retired, its identity, tokens, and downstream entitlements are revoked together. This is standard identity governance practice extended to a new population.

2. Separate the agent’s identity from the user’s authority

The most consequential design decision in agentic AI is how delegation works. There are two viable patterns:

On-behalf-of (delegated) access — the agent exchanges the user’s token for a scoped, short-lived token that carries the user’s entitlements, constrained to what the task needs. The agent can never exceed what the requesting user could do themselves. This is the safer default for agents serving individual users, and OAuth 2.0 token exchange gives you a standards-based way to implement it.

Agent-owned (autonomous) access — the agent holds its own narrowly-scoped entitlements, independent of any user. Appropriate for background automation such as reconciliation, monitoring, or ticket triage, where there is no human in the loop. Here the scope must be minimal and the monitoring aggressive, because there is no user permission ceiling to contain it.

The failure mode to avoid is the middle ground most pilots land in: an agent with broad, admin-like permissions serving many users, where every user effectively inherits the agent’s power. That is privilege escalation by architecture.

3. Make access ephemeral and just-in-time

Standing privilege is the risk that compounds. Agents should receive short-lived credentials, scoped to a single task or session, issued at the moment of use and expired immediately after. The privileged access management patterns enterprises already use for administrators — vaulting, brokered sessions, time-bound elevation, approval workflows for sensitive scopes — map directly onto agent access. If you have already built just-in-time elevation for humans, you have most of the machinery.

4. Log the reasoning, not just the request

Conventional access logs record that an identity called an API at a point in time. For agents that is insufficient. When something goes wrong, the questions are: which user prompted this, which agent handled it, what plan did it form, which tools did it invoke, and what data did it touch along the way. That requires correlating the originating user, the agent identity, the session, and every downstream call into a single traceable chain. Build this in from the start — retrofitting provenance into an agent platform after an incident is painful and often impossible.

What this means under Australian regulation

For APRA-regulated entities, CPS 234 obligations do not soften because the actor is an AI. Information assets accessed by agents still need classification, controls proportionate to criticality, and testing of control effectiveness. If an agent can read customer data, it sits inside your security control framework and inside your incident notification obligations. CPS 230 adds operational risk and service-provider considerations where the agent platform or model is vendor-supplied.

The Essential Eight also has a direct read-across. Restricting administrative privileges is the mitigation most obviously stressed by autonomous agents, and application control becomes interesting when an agent can decide at runtime which tools to invoke. Australian organisations should expect assessors to ask how agent identities are governed, not whether AI is in use.

Across APAC the pattern is similar — MAS technology risk guidelines in Singapore, and privacy regimes across the region, land on the same core question: can you demonstrate who or what accessed the data, under whose authority, and with what controls in place.

A practical starting sequence

Organisations that navigate this well tend to move in the same order:

1. Inventory the agents you already have. Copilots, automation scripts with LLM calls, vendor features switched on by a business unit. Most enterprises find more than they expected, and almost none of it is in the identity register.
2. Bring agent identities under governance. Owner, purpose, scope, expiry, and inclusion in access certification cycles.
3. Fix delegation before scale. Decide the on-behalf-of versus autonomous pattern per use case, and enforce it in the platform rather than by convention.
4. Eliminate standing credentials. Move agents to short-lived, task-scoped tokens brokered through your PAM platform or identity provider.
5. Instrument end-to-end traceability. User to agent to tool to data, in one correlated trail your security operations team can query.
6. Then expand. Scale agent use cases only once the first five hold under load.

This sequence deliberately mirrors the discipline that separates successful production deployments from stalled experiments — a theme we covered in Agentic AI for the Enterprise: From Pilots to Production. The organisations that get agents into production are the ones that solved identity first, because identity is what makes autonomy auditable.

Identity is the control plane for enterprise AI

The distinction between standard user access and privileged, non-human access is worth revisiting here. If that difference is not clear across your teams, our explainer on IAM vs PAM is a useful grounding before you design agent access.

The strategic point is simple. Every meaningful constraint you can place on an autonomous system — what it can see, what it can change, on whose authority, for how long — is expressed through identity. Model guardrails and prompt-level controls are useful, but they are advisory. Identity controls are enforceable. An agent that cannot obtain a token for a system cannot act on that system, regardless of what it decides to do.

Enterprises that treat agentic AI as an identity programme rather than purely an AI programme will move faster, because they will not have to stop and rebuild controls when the first agent does something unexpected in production.

Where Delivery Centric fits

Delivery Centric has spent years delivering identity and access management, privileged access, and identity governance programmes for banking, telecommunications, healthcare, and government clients across Australia and APAC. That same foundation is what agentic AI now depends on. We help organisations extend existing IAM and PAM capability to cover agent identities, design delegation and just-in-time access patterns that stand up to audit, and build the traceability regulators will ask for.

If you are piloting agents and want the identity architecture right before you scale, get in touch with our team for a working session on your current state and the gaps that matter. And if you would rather build this from the inside, we are hiring identity and cloud security specialists across our Australian and APAC offices — see our current openings.

Ask five people in an Australian enterprise security team to explain IAM vs PAM and you will often get five different answers. The two disciplines overlap, share vendors, and are frequently bundled into the same budget line — which is exactly why organisations end up with a well-run identity platform and a privileged access blind spot sitting right next to it. This article draws a clear line between the two, explains where they meet, and sets out how to sequence them so you are not paying twice for half the protection.

What IAM actually covers

Identity and Access Management is the discipline of establishing who someone is and what they are entitled to across your estate. It is a breadth problem. IAM is concerned with every identity in the organisation — employees, contractors, partners, customers and, increasingly, non-human identities like service accounts and AI agents.

A mature IAM capability typically delivers:

• Authentication — proving the identity is genuine, via single sign-on, multi-factor authentication, and increasingly passwordless methods.
• Authorisation — mapping identities to roles and entitlements so access matches the job, not the person’s tenure.
• Lifecycle management — provisioning on day one, adjusting on role change, and de-provisioning the moment someone leaves. Orphaned accounts remain one of the most common findings in Australian security audits.
• Governance and certification — periodic access reviews that give an auditor evidence that entitlements were examined and either confirmed or revoked.

The measure of good IAM is friction removed without control lost: people get the access they need quickly, and that access is provably correct. Our enterprise identity and identity governance practices are built around exactly that balance.

What PAM actually covers

Privileged Access Management is a depth problem. It governs the small number of accounts that can change the environment itself — domain admins, root, cloud tenant owners, database administrators, network device credentials, break-glass accounts, and the service accounts wired into your automation.

These accounts are a different risk class entirely. A standard user account leaks a mailbox. A compromised domain admin account leaks the domain. PAM exists because the blast radius justifies controls that would be intolerable if applied to everyone:

• Credential vaulting — privileged passwords and keys are stored centrally, rotated automatically, and never known to the human using them.
• Just-in-time elevation — standing admin rights are removed; access is granted for a defined window against a defined reason, then revoked.
• Session isolation, recording and monitoring — privileged sessions are proxied so the endpoint never touches the credential, and the session is recorded for forensic review.
• Secrets management for machines — API keys, certificates and service account credentials handled by a broker rather than hard-coded into scripts and pipelines.

The measure of good PAM is that no human holds a permanent key to anything critical. See our privileged access management capability for how that is implemented in practice.

IAM vs PAM: the difference in one table

Dimension	IAM	PAM
Population	All identities — thousands to millions	Privileged accounts — typically 1–5% of identities
Primary question	Is this the right person, with the right access?	Should this elevated action happen right now, and can we prove what was done?
Core controls	SSO, MFA, provisioning, role modelling, access reviews	Vaulting, rotation, just-in-time elevation, session recording
Access model	Persistent, entitlement-based	Ephemeral, request-and-approve
Failure mode	Access creep, orphaned accounts, over-provisioned roles	Standing admin rights, shared credentials, unmonitored sessions
Business driver	Productivity, onboarding speed, audit evidence	Breach containment, insider risk, forensic accountability

Why you need both — the gap between them is where breaches live

Attackers rarely land on a privileged account. They land on a standard one — a phished credential, an exposed contractor login, a stale account nobody de-provisioned — and then move laterally until they find something with elevation. That path crosses both domains.

IAM without PAM means you can prove who logged in, but not what they did once they escalated. Access reviews will happily certify a role that quietly carries a local admin right, because the review is looking at entitlements, not at what those entitlements permit at the operating system layer.

PAM without IAM is worse in a subtler way. You have a beautifully controlled vault protecting privileged credentials — and no reliable source of truth for who currently works here. When a privileged administrator leaves, the joiner-mover-leaver process is what removes their claim to the vault. Without it, PAM protects the credential but not the entitlement to request it.

The two also share a dependency that many programs discover late: identity data quality. Both disciplines rely on an authoritative HR feed, clean role definitions, and consistent account-to-owner mapping. If that foundation is weak, PAM will be onboarded around the problem — with manual approver lists and spreadsheet-maintained groups — and the control degrades within a year.

The Australian regulatory angle

For APRA-regulated entities, CPS 234 requires information security controls commensurate with the criticality and sensitivity of the asset, and the ability to demonstrate them. Privileged access is where that “commensurate” test bites hardest — a regulator will reasonably expect stronger controls around an account that can alter the environment than around a standard user login.

The ACSC Essential Eight makes the point even more directly. Restrict administrative privileges is one of the eight mitigation strategies in its own right, and the maturity model expects privileged access to be validated on first request, limited in duration, and separated from general-purpose computing. Multi-factor authentication, another of the eight, sits squarely on the IAM side. You cannot reach a credible maturity level on either without work in both domains.

For organisations across APAC, the same structural expectation appears under different names — MAS guidelines in Singapore, RBI directions in India — but the control intent is consistent: know your identities, and treat privileged ones as a distinct risk class.

Sequencing: what to build first

Most Australian enterprises we work with are not starting from zero. They have SSO, some MFA coverage, and a partially deployed vault. The practical sequence that avoids rework:

1. Establish identity truth. Authoritative HR source, joiner-mover-leaver automation, and a reconciled account inventory including service accounts. Everything downstream depends on this.
2. Discover privilege honestly. Run a genuine discovery across domain, cloud tenants, databases, network devices and pipelines. The count is almost always higher than expected — undocumented service accounts and legacy local admins are the usual surprises.
3. Vault and rotate the crown jewels first. Domain admin, cloud tenant owner, and production database credentials before anything else. Do not attempt a big-bang rollout across all privileged accounts.
4. Remove standing privilege. Move to just-in-time elevation for the vaulted tier. This is the step that most reduces blast radius, and the one most often deferred.
5. Close the loop with governance. Bring privileged entitlements into the same certification cycle as standard access, so reviewers see the full picture in one place.

Non-human identities deserve explicit mention. Service accounts, CI/CD pipeline credentials and — newly — autonomous AI agents now outnumber human identities in many estates. They authenticate like users and often carry privilege like administrators, which puts them squarely at the intersection of IAM and PAM. Treat them as first-class identities with owners, lifecycles and expiry dates, not as configuration.

Where this fits in a Zero Trust program

IAM and PAM are the two load-bearing pillars of any Zero Trust implementation. Zero Trust asks for continuous verification and least privilege by default; IAM supplies the verified identity and the entitlement model, PAM supplies the least-privilege enforcement at the point where privilege actually matters. If you are mapping out a broader program, our practical Zero Trust roadmap for Australian enterprises sets out how these pieces sequence together.

Talk to Delivery Centric

Delivery Centric has delivered identity and privileged access programs for Australian banking, telecommunications, health and government organisations, working across the major platforms in both categories. If you want a candid read on where the gap sits between your IAM and PAM controls, get in touch — we will start with a discovery conversation, not a product pitch.

Building an identity or cyber security team of your own? We are consistently hiring IAM, PAM and cloud security consultants across Australia and APAC — see our current openings.

Enterprise AI is entering a new phase. The last wave gave organisations chatbots and copilots that could answer questions and draft content. The emerging wave is agentic AI — systems that don’t just respond, but plan, take actions across tools, and complete multi-step work with limited human supervision. For Australian and APAC enterprises, the opportunity is significant; so is the need to deploy it safely. This is where Delivery Centric focuses: turning agentic AI from a promising demo into production capability that actually holds up in a regulated enterprise.

Continue reading “Agentic AI for the Enterprise: From Pilots to Production”