AI dominated discussions at last week’s Gartner’s Security and Risk Management Summit, with a clear focus on how organisations can adopt it securely and demonstrate its value. As automated systems take on more responsibility, reliable data, clear accountability, strong identity controls and proven recovery capabilities become increasingly important.
Integrity360’s CTO Richard Ford and Director of Product Management Brian Martin attended different combinations of sessions, bringing together perspectives from security operations, product strategy and service delivery. Their first-day reflections focused on the foundations organisations need before expanding their use of AI.
The strongest starting point for AI adoption is a clearly defined problem. Reducing investigation time, improving detection quality or making security decisions more consistent gives teams a practical basis for evaluating both the technology and its results.
Richard’s sessions emphasised an automation-first approach. Before introducing a model, organisations should consider whether conventional, rules-based automation can complete the task more reliably, explainably and economically.
Brian heard a complementary argument for shorter planning cycles. AI capabilities are developing quickly, and lengthy transformation programmes can leave organisations committed to assumptions that no longer hold. Smaller deployments allow teams to test an idea, measure its value and adjust their plans.
The shared conclusion was to begin with a bounded use case and an agreed measure of success. That gives security leaders something concrete to demonstrate when explaining investment decisions to the board.
The opening keynote encouraged cybersecurity teams to strengthen their engineering capabilities. Programming, API integration, automation and testing are increasingly relevant to how security services are developed and operated.
AI makes prototyping more accessible, but maintaining a useful production system still requires secure design, documentation, testing and ownership. Organisations need to consider who will support a custom capability, how it will be updated and what happens when its original developer moves on.
Building makes sense where specific requirements create a meaningful advantage and the organisation can sustain the result. Established products may provide better value where custom development adds complexity without improving outcomes.
For agentic systems, Richard and Brian reached a similar design principle: give agents narrow responsibilities and restricted permissions. The mechanisms coordinating those agents then need to enforce boundaries, manage approvals and provide an auditable record of activity.
Securing AI agents requires visibility of their identities, ownership, permissions and actions. These controls extend familiar identity governance responsibilities to systems that can operate quickly and across multiple applications.
Brian’s sessions explored the importance of discovering every identity, understanding its privileges and managing its lifecycle. Agents, workloads, service accounts and API keys all need appropriate ownership and oversight.
Richard’s observations connected identity directly to data and action. A record of prompts provides limited assurance when an agent can send information, modify records, delete files or execute commands. Organisations need to understand what each agent can reach and enforce restrictions while it operates.
This also makes existing identity weaknesses more urgent. Broad service-account permissions or poorly managed privileged access can give an automated system more authority than its purpose requires.
Brian’s session on deepfake impersonation examined how voice, video and social engineering can target help desks, payment approvals, executives and account recovery processes.
Detection tools can help, but organisations should plan for the possibility that a convincing impersonation will go undetected. High-impact requests need independent verification and approval processes that do not depend solely on recognising a voice or face.
Phishing-resistant authentication, stronger account recovery and clear escalation routes all contribute to protection. Staff must also feel able to pause an unusual request, even when it appears to come from a senior colleague.
The important test is whether one convincing interaction could bypass the wider control process.
Richard’s resilience sessions focused on the difference between a documented recovery objective and a demonstrated capability. A four-hour recovery time objective offers little assurance if restoring and validating the service takes substantially longer.
Recovery rehearsals, playbook exercises and rollback tests reveal dependencies and practical obstacles that written plans can miss. Their findings help teams improve procedures and give leaders evidence for investment decisions.
Paul Proctor’s proposed Protection Level Agreements extended this thinking to security commitments. Organisations should understand what level of detection, response or recovery is being delivered, how it is measured and which responsibilities remain with them.
For managed services, those expectations need to be explicit enough to support decisions about risk and funding.
Richard’s security operations sessions explored how automation could reduce repetitive triage and information gathering, allowing analysts to spend more time investigating ambiguity and leading incidents.
That shift depends on engineering discipline. Detections need to be tested, maintained and version-controlled, while automated recommendations must include enough evidence for people to assess them.
Human oversight becomes less effective when analysts receive an overwhelming volume of unexplained recommendations. Teams need manageable workloads, visible uncertainty and clear authority over consequential decisions.
The first day’s discussions established a practical order for progress: define the outcome, establish ownership and controls, then introduce automation where it can deliver a measurable improvement.
Speak to Integrity360 about strengthening identity security and incident readiness as part of your AI adoption plans.
Next in the series: Day two explores CTEM, secure AI development and the data foundations of an agentic SOC.
What Are Non-Human Identities?
Non-human identities represent systems such as workloads, service accounts and AI agents. They allow those systems to access resources and need ownership, appropriate permissions, monitoring and lifecycle management.
How Can Organisations Reduce Deepfake Impersonation Risk?
Use independent verification for sensitive requests, strengthen account recovery and establish clear approval processes. Detection tools can support these controls, while staff need the authority to challenge unusual instructions.
How Should Organisations Assess an AI Security Use Case?
Define the problem, identify the required data and permissions, assign an owner and agree how success will be measured. Test the capability within clear boundaries before expanding its responsibilities.