Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Most multi-site infrastructure teams manage access and audit logging site by site, using stacks that have been built up over time through different tools, different owners, and thousands of static credentials or standing admin privileges. This makes org-wide auditability nearly impossible to produce on demand, and adds complexity to regional compliance requirements.

Getting a certificate from a CA is a solved problem (ACME). Distributing it to the rest of your infrastructure is not. Your F5 has its own API. Your Palo Alto has a different one. Azure Key Vault is a third thing entirely, and the appliance in the back of the rack only has an SSH interface.

Editing IAM policies cannot fix the most common architectural mistake in shipping AI agents on Kubernetes. It happens in thirty seconds: a platform engineer reuses an existing ServiceAccount with an IRSA annotation for Bedrock access because creating a new one takes thirty minutes plus a Terraform pull request. The new agent ships under the existing identity.

Your risk committee meets Thursday. The agenda has a new item: AI agent risk posture. You open the register. The fraud detection agent shipped in March is on it. So is the customer service agent. Neither row is useful — “likelihood: medium, impact: high, control: service account scoped via IAM.” Three months ago that was approximately right. Last week the platform team added two MCP connections, the model was upgraded, and the agent now touches data classes the entry never anticipated.

As 2026 rolls on, our capacity to prompt ourselves silly appears to be limitless. We’ve already seen the financial, legal, and reputational damage to Deloitte as they partly refunded the Australian government for a 237-page audit report containing LLM-generated hallucinations like fabricated academic references, fake footnotes, and a false quote attributed to a judge.

Whether it’s vendors diagnosing GPU driver failures or network technicians troubleshooting switch configurations, organizations are often ready to do whatever it takes to get their infrastructure back to normal. For some, that may mean defaulting to the fastest access path available for third-party access, such as shared SSH keys, VPN credentials, or screen-sharing sessions.

You know your servers need hardening. Getting leadership to prioritise, fund, and support the effort is the harder challenge. Here’s our experts’ best advice for how to talk to the C-suite and board about the need for automated server hardening. You already know the servers are drifting. Configurations change. Exceptions pile up. Standards slip over time. The hard part is not identifying the problem.