Security teams need to adapt as technology, attacker behaviour and business requirements evolve. Doing that reliably requires controls that can be tested, adjusted and explained, alongside clear limits on what automated systems may do.

The final day of Gartner’s Security and Risk Management Summit brought these requirements into focus for Integrity360’s CTO Richard Ford and Director of Product Management Brian Martin. Sessions explored detection engineering, AI agent governance, operational resilience and the changing expectations of managed detection and response (MDR).

A recurring question was how organisations can demonstrate that a capability works well enough to rely on it.

Build an adaptable security operating model

Peter Hinssen’s opening keynote framed disruption as a continuing operating condition. Security teams need to learn and adjust without treating every change as an exceptional crisis.

Shorter feedback loops and modular controls can make it easier to revise priorities. Technology decisions also need to account for integration options and credible exit routes, particularly where AI products are developing quickly.

These choices help organisations retain control over their dependencies and avoid commitments that become difficult to change as requirements develop.

Make detection engineering a formal discipline

Detection engineering is the controlled process of developing, testing, deploying and maintaining detections against relevant threats.

Richard’s sessions challenged the value of rule counts and broad MITRE ATT&CK mapping as standalone measures of protection. A detection library only provides assurance when its rules are relevant, correctly implemented and supported by the necessary telemetry.

The process should begin with a prioritised threat scenario. Teams then confirm data availability, develop and peer-review the logic, test it before release and monitor its performance in production.

AI can support this work through specialised agents handling research, telemetry checks, rule creation or testing. Engineers remain responsible for quality, with approval requirements matched to the impact of the change.

Automated investigation also places greater demands on detection output. Agents need explicit evidence and parameters to continue an investigation safely. Missing context that an experienced analyst might recognise cannot simply be assumed.

Control agent goals and workflows

Richard’s identity sessions extended least privilege beyond access rights. Organisations also need to specify the goals an agent may pursue, which tools it can invoke and when human approval is required.

This becomes particularly important in multiagent systems. Permissions that appear acceptable individually can combine across a workflow to bypass segregation of duties.

Every agent therefore needs a discoverable identity, a named owner and clearly bounded authority. Existing weaknesses in standing privilege or service-account governance need attention before those permissions are used at greater speed and scale.

Responsibility for outcomes must also remain explicit. Cybersecurity teams own security controls, while business, product and data owners retain accountability for an agent’s purpose and the decisions made using its outputs.

Govern citizen development according to impact

Richard’s sessions explored how employees can create applications and agents without necessarily understanding trust boundaries, failure modes or maintenance requirements.

Approved patterns, restricted environments, documentation expectations and proportionate testing can make this activity more manageable. Controls should reflect consequences: a low-impact assistant requires different oversight from an agent that changes production systems, transfers funds or communicates externally.

Coding agents may also help address technical debt, but generated changes still need review, security testing and regression testing. The ability to make changes quickly increases the importance of knowing whether they are safe to release.

Prepare for more vulnerability findings

Richard and Brian both attended Dionisio Zumerle’s discussion of AI-assisted vulnerability discovery. Their takeaway was that organisations need to prepare for more potential findings and greater pressure on prioritisation.

Reachability, exploitability and asset importance should guide the response. Low-risk fixes may be suitable for automation where validation and rollback are reliable. Critical exposures need an emergency route, while systems that cannot be patched may require isolation or other compensating controls.

Faster discovery creates value when it leads to a timely, well-supported decision and a response that reduces exposure.

Put operational context at the centre of OT Security

Sessions on cyber-physical systems reinforced familiar requirements: discover assets, segment environments, control access and monitor activity. Their effectiveness depends on an accurate understanding of operations.

A vulnerability score cannot establish whether a device is essential to production or whether taking it offline would create a safety risk. Asset criticality must account for dependencies, operational impact and decision-making authority.

Security and engineering teams need shared processes for assessing interventions. This allows them to reduce exposure while protecting safe and reliable operations.

Require evidence from AI-supported security testing

Brian’s Synack session examined the difference between an AI demonstration and a dependable penetration testing service.

Production readiness requires scope control, repeatability, verification, safety and support. The system coordinating the testing must determine which tools agents can use, where they may operate and when they must stop.

Findings used to guide customer decisions need reproducible evidence and appropriate human review. Reliability must be established across the full service, including how unexpected behaviour is handled.

Brian’s AI risk framework session made a related point about governance. Frameworks provide value when their principles become practical controls: named owners, defined permissions, testing requirements and monitoring after release.

Explain MDR through measurable outcomes

In a one-to-one discussion with Gartner analyst Paul Furtado, Brian explored how expectations of MDR are developing. This was an analyst conversation rather than a formal presentation, but it provided a useful perspective on service design.

The discussion pointed towards growing expectations for rapid, increasingly automated response and broader connected capabilities. Providers need to explain what those capabilities achieve for customers.

Boards need evidence of reduced risk and stronger resilience. Security teams need the technical detail behind those claims, including detection health, response performance and remaining gaps.

For Integrity360, the final day reinforced the importance of combining engineering quality with clear accountability. Security capabilities earn trust through repeatable performance and evidence that supports the decisions customers need to make.

Speak to Integrity360 about strengthening detection and response, securing AI identities and improving operational resilience.

The final blog in this series brings together the summit’s main themes and their implications for cybersecurity leaders.

FAQs

How Should Detection Engineering Be Measured?

Useful measures include detection health, test success and effective coverage against prioritised threats. Rule counts alone do not establish whether detections work or support reliable investigations.

What Makes AI-Supported Penetration Testing Production-Ready?

It needs controlled scope, repeatable methods, verified findings, safe operation and dependable support. Human review remains important where findings influence customer decisions.

Why Does OT Security Require Operational Context?

Security changes can affect physical processes, production and safety. Decisions need to account for asset dependencies and operational consequences as well as technical severity.