Highlights: Controls that lag the systems they govern

Editor’s Note

Digital risk programs face a common problem that shows up in different forms across governance, cybersecurity, audit, identity, insurance, data protection, and enterprise technology. Organizations generally know which controls they have implemented. The harder question is whether those controls still operate at the speed, scale, and complexity of the environments they are meant to govern.

This week's developments explore that challenge from several directions. Regulators are encouraging organizations to align controls with the relationships and risks they manage. Security leaders are confronting shrinking response windows and increasingly automated threats. Audit functions are being asked to demonstrate measurable impact rather than simply document observations. Identity teams are extending governance beyond people to include agents, tokens, and machine accounts. Insurers are examining the controls and recovery assumptions that sit behind coverage decisions. Privacy teams are managing data that increasingly resides outside traditional boundaries, while enterprise platforms are being expected to enforce controls rather than merely record them.

The common question across all of these developments is straightforward: can the organization explain what a control governs, who owns it, and how it operates when conditions change?

Deep Research

1. GRC (Governance, Risk & Compliance)

On September 11, the Federal Reserve, FDIC, NCUA, and OCC requested comment on proposed principles-based guidance for third-party risk management. The proposal is non-binding and, once finalized, would replace the agencies' existing third-party risk guidance. Financial institutions would be expected to tailor controls, monitoring, and oversight to the specific risks presented by each third-party relationship.

The agencies also released a joint statement focused on community banks and the core service providers that support critical banking operations. At the same time, the Federal Reserve published a companion guide intended to help community banks apply the proposed principles in practice and evaluate third-party relationships based on their operational significance and risk.

The proposal does not introduce an entirely new approach to third-party risk management. It reinforces an expectation that controls be designed around the relationship being managed. A core processor, cloud provider, critical software vendor, and low-risk service provider should not be assessed through exactly the same process simply because they are all classified as third parties. The issue is not whether a vendor exists in the inventory. The issue is whether the organization understands the dependency, the associated business risk, and the controls required to manage it.

That same design challenge is now appearing through generative AI adoption.

Palo Alto Networks' C-Suite Guide to GenAI Risk Management begins with a practical question: how are AI capabilities actually entering the organization? The guide identifies four common paths: public AI applications, marketplace plugins, connected APIs, and AI capabilities already embedded within approved SaaS platforms.

The distinction matters because each path creates a different risk profile. An employee using a public AI application creates one set of concerns. A plugin connected to sensitive data creates another. A sanctioned SaaS platform that quietly enables new AI capabilities may introduce risks that neither security nor compliance teams have explicitly reviewed.

Palo Alto recommends classifying these pathways as sanctioned, tolerated, or unsanctioned and building visibility around how they are used. The primary failure points are limited visibility, weak access controls, unvetted plugins, and sensitive information being submitted to systems outside established governance processes. The recommended operating model includes shadow-AI discovery, application classification, granular access control, outbound traffic inspection, plugin governance, and inspection of data at rest.

The issue is not whether employees have access to an approved GenAI tool. The issue is whether the organization can identify where AI is being used, what information is being exposed, and which controls govern that use. Adoption is activity. Reduced unauthorized use and fewer data exposure events show that controls are working.

OCEG's 2026 ICEP guide, Building Your Compliance Blueprint, reaches a similar conclusion from a compliance perspective.

The guide describes a mid-sized financial institution that inherited 47 policies, 12 training modules, and a 200-page compliance manual. Despite that investment, the compliance officer could not identify the organization's three most important compliance objectives or explain how the program supported business goals.

OCEG's ALIGN framework starts elsewhere. Direction is tied to the business mission. Objectives support business goals. Obligations are inventoried and prioritized. Controls are designed to prevent, detect, or respond to meaningful risks.

The sequencing matters.

Organizations often begin with policies and attempt to prove compliance afterward. OCEG argues that compliance programs should start with business objectives and then determine which obligations and controls matter most to achieving them.

An anti-money-laundering failure does not carry the same consequence as a minor record-retention issue. A critical service-provider outage does not create the same level of exposure as a low-risk vendor disruption. Not every obligation, relationship, or control carries the same business impact.

The same test applies across all three examples.

A third-party relationship should map to a business objective and a defined owner.

A GenAI capability should map to a specific use case, defined data boundaries, and accountable oversight.

A compliance control should map to an obligation the organization considers important enough to manage.

If a relationship, tool, policy, or control cannot be connected to a business objective, a defined risk, and a responsible owner, the organization is maintaining activity rather than oversight.

Before the comment period closes, organizations should review their critical third parties, their generative AI inventory, and their highest-priority compliance obligations using the same question:

Can the control clearly explain what it governs, why it exists, and who owns it?

If it cannot, the control likely needs more attention than the relationship it was designed to manage.

Sources

Federal Banking Agencies’ Proposed TPRM Guidance

Palo Alto Networks C-Suite Guide to GenAI Risk Management

OCEG: Building Your Compliance Blueprint

2. Cyber Security

Cybersecurity programs are increasingly being measured by how quickly an organization can detect, assess, and respond to a confirmed threat. McKinsey examined that challenge through the shrinking window between vulnerability disclosure and exploitation. Claims Journal highlighted it through settlement-layer custody and authorization. Microsoft demonstrated it through social engineering campaigns that move from initial contact to account compromise within hours. Reco approached the same issue from a procurement perspective. Each points to the same problem: response time is becoming a more significant security control than documentation.

McKinsey's September analysis, The Speed Problem, describes how rapidly the threat environment has changed. Industry data cited in the report estimates that mean time to exploitation for the most critical vulnerabilities fell from about 23 days in 2025 to roughly 20 hours in 2026. The emergence of frontier models that can generate exploit code at low cost has contributed to that acceleration.

The challenge is rarely identifying the vulnerability. The challenge is moving from awareness to action. Asset inventories, application-owner approvals, custom testing cycles, production freezes, and vendor patch schedules all introduce delays. Many organizations still rely on governance and change-management processes designed for a threat environment that moved much more slowly.

McKinsey recommends not eliminating human oversight. Instead, it recommends reserving human decision-making for novel and material risks while allowing preauthorized automation to handle routine monitoring and remediation activities. The practical objective is to shorten the time between detection and response. Organizations should evaluate whether security teams have sufficient visibility, delegated authority, and operating procedures to isolate systems, revoke credentials, or contain confirmed threats without unnecessary delay.

The Liquid Network incident on September 8 illustrates how similar delays can emerge outside traditional enterprise security environments. Approximately 4,000 Bitcoin, valued at roughly $320 million, was removed from wallets associated with the network's settlement layer. According to reporting cited by Claims Journal, self-described white-hat actors later returned most of the assets while retaining approximately $47 million. Liquid stated that the settlement-platform authorization key had not been compromised.

The more important lesson lies in where the failure occurred. The incident did not center on an endpoint, user device, or phishing campaign. It occurred within the custody, wallet-management, and settlement processes that support digital asset operations. DefiLlama data cited in the same reporting estimated approximately $1.4 billion in thefts across roughly 250 attacks during 2026, with a growing percentage targeting bridges and settlement infrastructure. These environments often fall between traditional operational ownership boundaries even though they support critical financial activity.

Microsoft disclosed two separate campaigns that illustrate how quickly similar risks can materialize inside the enterprise. In one campaign, threat actors sent more than one million CEO-themed invoice emails between August 3 and August 5, encouraging accounts-payable teams to initiate ACH transfers for a fictitious ServiceNow subscription. A second campaign, active since May, relied on passkey, multifactor authentication, and single sign-on helpdesk lures.

After a successful support interaction, attackers added their own authenticator and accessed email, SharePoint, and OneDrive data through Microsoft Graph. None of those actions appeared unusual in isolation. The risk emerged from the sequence of events. A helpdesk interaction became an authentication change. The authentication change became access. The access became data exposure.

The pattern reinforces an important lesson for defenders. Modern attacks increasingly resemble legitimate activity. Organizations that focus exclusively on individual events may miss the broader chain of actions that indicates compromise.

Reco's AI security evaluation framework provides a useful lens for assessing whether security investments address these evolving risks. The framework recommends evaluating vendors across workforce AI, product AI, and engineering AI while examining discovery capabilities, data exposure controls, governance functions, detection mechanisms, and protections designed for autonomous and agentic systems.

The standout recommendation is to validate claims under realistic conditions. A proof of concept should not simply demonstrate what works when the vendor is prepared. It should include testing scenarios the vendor does not anticipate to determine how controls perform under less predictable conditions.

The common theme across these developments is that cybersecurity increasingly depends on an organization's ability to make and execute decisions quickly. Exploitation timelines are shrinking. Attackers are blending into legitimate workflows. Critical infrastructure dependencies continue to expand. At the same time, many response processes still reflect assumptions from a much slower environment.

Organizations should review who has authority to act when a material threat is confirmed, what actions can be taken immediately, and what decisions still require escalation. The issue is not whether governance exists. The issue is whether governance supports the speed required to manage the threats it is intended to control.

Sources

Claims Journal: Liquid Network $320 Million Hack

Reco AI Security Vendor Evaluation Framework

The Hacker News: Passkey Phishing Against Microsoft Cloud Accounts

McKinsey: The Speed Problem in Enterprise Cybersecurity

3. Internal Audit, IT Audit & Continuous Control Monitoring

Internal audit has traditionally focused on reporting exceptions, validating controls, and assuring whether processes operate as intended. This week's developments raise a different question: how should audit demonstrate value when governance failures, AI adoption, and organizational change increasingly occur between audit cycles? The examples that follow examine that question from three angles: board governance, measuring audit impact, and the shift from calendar-based assurance to risk-triggered oversight.

On September 9, Coforge announced that O.P. Bhatt resigned as non-executive independent director and chairman after an internal audit reviewed the board evaluation process he oversaw. The audit identified process and disclosure gaps, including issues associated with the chairman's own performance evaluation. According to the company, the Board did not fully disclose material information in the Board Evaluation Report when it was presented. Bhatt stated that he acted in good faith and resigned before the review was completed. Vivek Sharma was appointed interim chairman through January 31, 2027.

The significance extends beyond an individual resignation. Internal audit rarely examines a process more closely tied to governance than evaluating the board itself. When audit reviews how directors are assessed, the focus shifts from operational controls to transparency, independence, and accountability. The finding matters because it affects confidence in the governance process that oversees the rest of the organization. In this case, the question was not whether a control operated correctly. The question was whether the process used to evaluate leadership could withstand scrutiny.

Edward Ansah's August 28 article in Internal Auditor examines a different challenge. Most audit functions already provide reports that include observations, criteria, root causes, recommendations, and management responses. Yet many audit committees still struggle to explain the value internal audit creates beyond the number of findings issued or recommendations accepted.

Ansah argues that audit functions should measure and report outcomes, not just observations. His framework separates recoveries, cost savings, revenue protection, and loss avoidance while documenting the source of the benefit, management's agreed action, financial impact, and the basis for measurement. Examples include procurement savings of $193,300; loss avoidance of $67,200; fee-assurance recoveries of $56,300 combined with $344,500 in protected revenue; and fraud-related recoveries and avoided losses totaling $50,000.

The broader point is not the dollar amounts. It is the need to connect audit activity to business outcomes. Audit should not claim value before management acts, but committees should also be able to see what changed because of the work performed. A list of findings shows what was observed. A value framework shows the effect of addressing the issue.

EY addresses the same challenge through AI governance and audit planning. The firm recommends moving away from treating AI as a topic that appears once a year on the audit calendar. Instead, audit activity should respond to specific events: deployment of a high-impact use case, a material model change, the introduction of a new data source, regulatory developments, AI capabilities embedded in third-party products, or sustained control-threshold breaches.

The recommendation reflects how quickly technology and risk are changing. An annual audit plan may remain compliant with governance requirements while becoming disconnected from the organization's actual risk profile. A trigger-based approach allows audit resources to follow changes in business operations, technology, and regulation as they occur.

EY also reinforces the role of the three lines. The first line manages AI implementations and operational use. The second line sets policy and oversees models. The third line evaluates governance, assesses controls, and provides assurance over both the framework and its application.

These examples describe different issues, but they point to the same evolution in internal audit. Governance reviews are expected to influence accountability. Audit reporting is expected to demonstrate measurable outcomes. Audit plans are expected to respond when risk changes, not when the calendar turns.

A useful question for audit committees is whether the most recent audit report changed a decision, altered governance, influenced resource allocation, or reduced exposure to a material risk.

If the answer is unclear, the organization may be measuring audit activity more effectively than audit impact.

Sources

Moneycontrol: Coforge Chairman Resigns After Internal Audit

Internal Auditor: A Better Way to Demonstrate Value

EY: How Internal Audit Can Adapt to AI

4. Identity Management / IAM

Identity programs were designed around people, devices, and applications. Agentic AI introduces a different challenge: how should organizations govern identities that can make decisions, access systems, and act on users' behalf? This week's developments approach that question from several directions, including collaboration platforms, agent authorization models, identity governance, and the long-standing challenge of maintaining a single, authoritative identity. Together they highlight a growing need to rethink identity as a runtime control rather than a static administrative function.

Cloud Security Alliance highlighted Akto's August 11 analysis of Anthropic's Claude Tag, which allows an AI agent to participate in shared Slack channels while maintaining identities in connected systems. Administrators establish a baseline workspace configuration and then apply controls at the channel level. Private channels receive separate identities, and credentials are injected only into approved destinations.

The model provides flexibility, but it also introduces new identity and authorization challenges. A user who cannot directly access a repository may be able to obtain information through the agent if the channel profile permits that access. Responses are visible to everyone within the channel, audit logs reflect actions performed by the agent rather than the individual requester, and channel membership effectively becomes an authorization mechanism. Prompts are temporary, making it difficult to reconstruct intent after the fact.

The issue is not simply whether the agent has an identity. The issue is whether the organization can consistently determine who requested the action, what permissions were used, and whether the action should have been permitted in the first place. Akto notes that a more identity-aware approach, one capable of evaluating both the user's permissions and the agent's permissions at runtime, remains under development.

TrustLogix examined a related challenge through the concept of least privilege for autonomous agents. Citing a Gartner report from May 2026, the company noted predictions that 40 percent of enterprises may demote or decommission autonomous agents by 2027 because governance gaps emerge after deployment.

The concern is that many organizations continue to apply identity controls as though agents operate like traditional applications. Organizations grant access during deployment and review it periodically afterward. Agentic systems operate differently. Tasks change. Context changes. Risk changes. A privilege model established during implementation can become outdated as organizations introduce new tools, workflows, and data sources.

TrustLogix argues that authorization decisions should increasingly occur when an action is requested. Identity remains important, but identity alone does not provide enough context. Authorization increasingly requires evaluating attributes, roles, purpose, intent, data sensitivity, and the specific action being requested. The expansion of Microsoft 365 Model Context Protocol servers into Teams, Calendar, Mail, and additional services shows how quickly access assumptions can become outdated as an ecosystem expands.

IDC's September 2026 paper, Managing Agentic AI Through the Identity Control Plane, extends the discussion to enterprise-scale governance. Based on input from 13 industry leaders, the paper identifies several recurring challenges: organizations cannot accurately inventory their agents, privileged-access management processes were designed for people rather than autonomous systems, privilege accumulates rapidly, ownership is often unclear, and AI capabilities frequently appear through vendor platforms before governance teams are aware of them.

The research suggests that identity remains one of the few enterprise control mechanisms that can scale alongside autonomous systems. Yet the supporting processes remain immature. IDC reported that only 27.3 percent of organizations have fully automated identity reviews and fewer than one in five conduct continuous identity discovery. At the same time, nearly 30 percent are increasing the autonomy granted to AI systems.

Participants agreed: every agent should have a named human sponsor, a defined purpose, and a managed lifecycle. Organizations may automate tasks, but accountability still requires an identifiable owner.

Turnkey's guidance for higher education highlights the same principle from a more traditional identity perspective. The firm argues for a single authoritative identity supported through entitlements rather than creating multiple accounts for the same individual. Before merging records, organizations should be able to demonstrate that both identifiers belong to the same person.

Although the technology differs, the underlying governance challenge remains familiar. Identity systems create value when ownership, authorization, and accountability remain clear. They create risk when actions can no longer be tied back to an approved purpose or responsible party.

These examples point to a broader shift in identity management. Organizations have spent years refining authentication and access management for human users. Agentic systems require equal attention to authorization, ownership, and continuous governance.

A useful test is whether the organization can answer four questions for every agent operating in the environment: What systems can it access? What actions can it perform? Who is responsible for it? How is authorization evaluated when sensitive actions are requested?

If the organization can't answer those questions consistently, it may have deployed agents before establishing the identity control plane needed to govern them.

Sources

CSA / Akto: Seven Claude Tag Security Risks

TrustLogix: Least Privilege for AI Agents Is a Funnel

IDC / GuidePoint: Managing Agentic AI Through the Identity Control Plane

Turnkey: Single Digital Identity in Higher Education

5. Cyber Insurance

Cyber insurance has traditionally been evaluated through coverage limits, pricing, and renewal outcomes. Recent developments suggest a broader question is emerging: how well do organizations understand the operational risks, recovery assumptions, and AI-related exposures sitting behind the policy? This week's developments examine that question from three perspectives: loss trends, recovery performance, and the evolution of coverage language as insurers begin addressing AI-related risk.

RPS National Cyber practice leader Steve Robinson highlighted an increasingly unusual market dynamic. Paid ransomware losses during the first half of 2025 increased approximately 22 percent compared with the same period in 2024, yet pricing across much of the cyber insurance market remains relatively stable, and capacity remains abundant.

The underlying loss picture is becoming more complex. School districts continue to experience seven-figure claims. Healthcare-related organizations and service providers are seeing higher loss severity. Ransomware-as-a-service operations and AI-enhanced social engineering campaigns, including deepfake-enabled fraud, are shifting losses away from purely technical failures and toward human decision-making, process weaknesses, and operational controls.

The discussion around shadow AI introduces another layer of exposure. An employee entering client information into a public AI model may create cyber, professional liability, regulatory, or privacy implications depending on the circumstances and resulting harm. Insurers have begun incorporating AI-related questions into middle-market and large-enterprise renewals because they are increasingly trying to understand how organizations govern these risks before a claim occurs.

The issue is not whether pricing remains favorable today. The issue is whether current underwriting assumptions continue to align with emerging sources of loss.

Cohesity's fifth Global Cyber Resilience Report examines the same challenge from a recovery perspective. Based on research conducted by Vanson Bourne among 3,200 IT and security leaders, the report found that three-quarters of organizations experiencing a material cyberattack and business interruption during the previous year failed to meet their stated recovery-time objectives. Actual recovery times were nearly twice as long as planned.

The findings suggest that many recovery assumptions remain untested until an incident occurs. Eighty-six percent of organizations believed operations could resume once core systems were restored. Eighty-eight percent acknowledged that real-world response efforts would require significant improvisation. Seventy-eight percent reported focusing more heavily on restoring systems than maintaining business operations during recovery.

Among organizations that experienced an incident, additional challenges emerged after restoration efforts began. Sixty-three percent struggled to reconcile activity occurring after the most recent backup. Sixty percent lacked confidence that restored data was clean. Another sixty percent experienced identity-related issues during recovery.

These findings highlight an important distinction. The ability to restore technology is not always the same as the ability to restore business operations. Recovery plans increasingly depend on validating data integrity, resolving identity issues, and demonstrating that systems can safely return to service without reintroducing the original compromise.

Will Lassalle's September 15 analysis approaches the issue from the perspective of policy language and coverage structure. In January, ISO introduced a generative AI exclusion within commercial general liability forms. Similar exclusions have begun appearing across directors and officers, employment practices liability, and fiduciary coverage. Verisk is reportedly evaluating language related to agentic AI, while regulatory requirements for AI transparency continue to evolve internationally.

These developments create new questions for risk, legal, and insurance teams. Organizations are increasingly deploying AI systems that influence recommendations, decisions, communications, and business processes. When a failure occurs, determining which policy responds may become less straightforward than it has been with traditional cyber events.

The practical exercise is simple. Select a plausible AI-related incident and trace the resulting claim across cyber insurance, technology errors and omissions coverage, directors and officers liability, professional liability, and general liability policies. The objective is not to predict every scenario. The objective is to identify gaps before a claim forces the question.

Each of these developments points to a broader shift in cyber insurance. Rising losses, recovery challenges, and evolving policy language are placing greater emphasis on the controls, governance practices, and recovery capabilities that sit behind the policy.

A favorable renewal does not necessarily indicate that the underlying exposure is well understood.

A useful question for organizations is whether security, legal, risk, and insurance stakeholders can clearly explain three things: how a material cyber event would be recovered, how an AI-related loss would be classified, and which policy would ultimately respond.

If those answers remain uncertain, the organization may be relying on insurance as a risk-management strategy before fully understanding the risk it intends to transfer.

Sources

Will Lassalle: The Insurance Market Just Priced Your AI Risk

RPS: Cyber Is Breaking Away From the Pack in Executive Lines

Cyber Insurance News: Cohesity Recovery Time and Business Interruption

6. Data Protection

Most data-protection programs can describe the records they manage today. The harder question is whether they can account for the records stored by vendors, governed by evolving privacy definitions, or retained long after the systems that created them have been retired. This week's developments examine those challenges through a third-party ERP breach, proposed changes to Australia's privacy framework, and the continuing obligation to govern historical records.

Bimbo Bakeries USA confirmed that employee Social Security numbers were exposed after a third-party vendor exploited a zero-day vulnerability in Oracle E-Business Suite. According to a filing with the California Attorney General dated September 4, 2026, the company became aware of the incident on December 6, 2025, and later determined on August 19, 2026, that one acquired file contained employee names and Social Security numbers. The company applied emergency Oracle patches, conducted a forensic review, offered affected individuals credit monitoring, and said it is reevaluating vendor relationships.

CyberPress reported that the timeline aligns with CVE-2025-61882, a critical remote-code-execution vulnerability affecting Oracle E-Business Suite BI Publisher Integration. Mandiant traced exploitation activity to August 2025, before Oracle released emergency patches.

The incident highlights a challenge many organizations still underestimate. Sensitive records increasingly reside in business-critical platforms operated through third-party relationships. Security teams often maintain inventories of corporate systems while assuming vendor-managed environments receive the same oversight. The issue is not whether personal data exists. The issue is whether the organization can identify where that data resides, who operates the platform that stores it, and how it would detect exposure if it loses control of that environment.

Australia's Attorney-General's Department approached the issue from a different perspective through the Exposure Draft of the Privacy Amendment (Personal Data Protection) Bill 2026. The proposal expands several core privacy concepts, including location-tracking information associated with an individual's movements over time. It also introduces a fair-and-reasonable handling requirement, strengthens consent and notification obligations, proposes a 72-hour reporting requirement for certain serious breaches, and creates additional obligations related to security, destruction, and data governance.

The proposal remains a draft, but it highlights how privacy obligations continue to evolve. Information that may have been outside a compliance program's primary focus can become regulated as legal definitions change. Organizations cannot assume their data classifications, inventories, and retention models will remain aligned with future regulatory expectations simply because they satisfy current requirements.

The DPO Center's guidance highlights the same challenge through historical records. GDPR obligations do not disappear because information was collected years ago or stored in systems that are no longer in production. Archived databases, decommissioned applications, exported files, employee SharePoint folders, off-site storage facilities, and paper records may all remain subject to current legal obligations.

Many organizations have mature processes for governing active systems but considerably less visibility into older information stores. Yet data-subject access requests, deletion requests, investigations, and litigation frequently require information that sits outside day-to-day operational environments. A retention schedule provides limited assurance if the underlying records cannot be identified, reviewed, or removed when required.

The examples differ, but they expose a similar challenge. Vendor-hosted platforms extend the organization's data footprint beyond internally managed environments. Regulatory changes can expand what qualifies as protected information. Historical records continue to create obligations long after the business process that generated them has disappeared.

A useful exercise is to test all three assumptions at once. Which third-party platforms contain workforce, customer, or sensitive business information? Which categories of information would fall under proposed privacy definitions but aren't currently tracked? Which archived data stores would be difficult to locate, review, or delete if a request arrived tomorrow?

The issue is not whether the organization has a current inventory.

The issue is whether it can account for the data it still owns and is responsible for.

Sources

DPO Center: How to Apply the GDPR to Historic Records

Australia Exposure Draft: Privacy Amendment Bill 2026

CyberPress: Bimbo Bakeries USA Data Breach

7x. Enterprise Digital Risk Products

Enterprise risk and security platforms are facing new expectations as organizations introduce agents, AI-assisted operations, and increasingly autonomous workflows. The challenge is no longer limited to storing records, documenting controls, or collecting evidence. Products are increasingly expected to help enforce controls, contain risk, and respond to change as it happens. This week's developments examine that shift through agentic email security, critical SAP vulnerabilities, and the evolution of GRC platforms.

On September 14, AWS described how Abnormal AI uses Amazon Bedrock AgentCore Code Interpreter to support agentic email security operations. According to AWS, the architecture uses a three-tier analysis model: lightweight heuristics evaluate billions of messages daily, more advanced models review millions of messages, and specialized agents operating inside a code sandbox investigate the subset of events that would otherwise require human analyst review.

Abnormal reported that agents now participate in the majority of its code-development process, with many changes generated end-to-end through agent-assisted workflows. Additional analyst agents continuously evaluate results and propose new heuristics for lower-level detection layers.

The notable design choice is not the volume of automation. It is the containment model surrounding it. The Code Interpreter environment operates within a no-egress sandbox, preventing threat-intelligence data from leaving the environment even if the agent encounters unexpected instructions or malicious inputs.

The example highlights an increasingly important design principle for AI-enabled security platforms. As agents gain access to sensitive information and decision-making workflows, organizations must treat the supporting environments as operational infrastructure rather than auxiliary features. Ownership, network boundaries, monitoring, and validation become part of the control structure.

SAP's September patch cycle illustrates the same issue from a different perspective. One of the most severe vulnerabilities addressed this month, CVE-2026-44756, affects SAP kernel processing of Extended Passport data and received a CVSS score of 10.0. According to Onapsis, the flaw allows remote code execution without authentication and can result in operating-system-level command execution with SAP administrative privileges.

The vulnerability is particularly important because of where it occurs. The vulnerable processing path sits inside shared kernel code and is reachable before authentication. Traditional authorization controls, segregation-of-duty rules, and user-level permissions offer little protection when the vulnerable component runs before those controls apply.

A second critical vulnerability, CVE-2026-58240, affects the SAP NetWeaver Message Server and similarly allows remote code execution because of a missing authentication control.

These vulnerabilities highlight a recurring challenge in security architecture. Organizations often focus attention on controls that govern access after authentication while assuming the underlying platform remains trustworthy. When critical flaws emerge beneath that layer, the effectiveness of higher-level controls depends on how quickly organizations identify, prioritize, and remediate the exposure.

Michael Rasmussen's September 15 discussion with IBM OpenPages principal product manager Ian Francis approaches the issue from a governance perspective. Rasmussen argues that the next generation of GRC platforms must evolve beyond traditional systems of record and become systems that can interpret change.

The distinction matters because organizations now face a growing volume of regulatory updates, third-party dependencies, AI models, and interconnected controls. Recording information remains important, but governance teams increasingly need help understanding how a change affects processes, vendors, risk assessments, policies, and controls across the enterprise.

A platform that simply stores requirements leaves the analysis to people. A platform that connects a regulatory change to affected business processes, vendors, controls, and AI systems helps organizations respond faster and more consistently.

These examples describe different technologies, but they point toward the same transition. Security and risk platforms are increasingly being asked to execute controls rather than simply document that a control exists.

Agentic security systems must contain and verify autonomous activity. Enterprise platforms must identify and remediate flaws that sit below traditional authorization controls. GRC platforms must help organizations understand how changes propagate across the business.

The practical question is no longer whether a product can collect information.

The question is whether it helps the organization control risk when conditions change.

Sources

AWS: Abnormal AI and Bedrock AgentCore for Email Security

The Hacker News: SAP CVSS 10.0 Kernel Flaw (OVERPASS)

Hitchhiker’s Guide: IBM OpenPages and GRC 7.0

Weekly Digital Risk Topics Trending on X

1. GRC (Governance, Risk & Compliance)

Artificial intelligence, automation, and increasingly sophisticated fraud schemes are changing what boards and audit committees expect from assurance functions. Traditional audit responsibilities remain important, but leaders are increasingly asking different questions: What value is AI creating? Which emerging risks need attention before they become incidents? Where are cyber, fraud, and operational risks beginning to overlap? This week's posts explore those questions through AI adoption, the evolution of audit planning, and a real-world fraud scenario that combines technology and human behavior.

The Cyber Security Hub highlighted reporting suggesting that many chief audit executives still struggle to explain the business value created by artificial intelligence initiatives within the audit function.

The challenge is becoming increasingly relevant as organizations invest in AI-enabled assurance capabilities. Audit committees may understand AI's potential to improve efficiency, expand coverage, or accelerate testing, but those benefits are hard to evaluate without clear measures of success. A pilot, a productivity improvement, and a strategic control enhancement are not the same thing.

Before approving additional investment, audit leaders should be able to explain how value will be measured, whether through improved coverage, reduced manual effort, faster identification of risk, or better assurance outcomes.

Source: @TheCyberSecHub

Norman Marks highlighted an Accounting Times article describing the evolution of internal audit from assurance toward foresight.

The discussion reflects a broader shift occurring across governance and risk functions. Traditional assurance activities focus on validating controls and evaluating what has already occurred. Organizations now operate in environments where technology, regulation, and business processes can change significantly between audit cycles.

The question is not whether assurance remains important. The question is whether audit functions can also provide visibility into risks that are still developing. Boards increasingly need insight into emerging issues before they appear as findings in a report.

Audit plans should therefore be evaluated not only on the coverage they provide, but also on their ability to identify changing risk conditions early enough for management to respond.

Source: @normanmarks

The Institute of Internal Auditors shared a blog by Maja Milosavljevic examining a refund scam that combined cyber compromise with social engineering techniques.

The example illustrates how fraud risk increasingly sits at the intersection of technology, process, and human behavior. A compromised account, a convincing request, and a well-intentioned employee can create financial loss even when individual controls appear reasonable on their own.

Refunds, reimbursements, recovery requests, and exception-handling processes are often viewed as customer-service activities. They should also be viewed as fraud-control points. Organizations should regularly test whether a compromised identity combined with persuasive communication can trigger movement of funds before appropriate review occurs.

Source: @TheIIA

2. Cyber Security

Attackers continue to compress the time between access, escalation, and impact, forcing organizations to reconsider where security controls should sit and how quickly they must operate. This week's posts examine that challenge through early-stage intrusion detection, privilege escalation, and security assessments for organizations handling sensitive government information. The common question across all three is straightforward: does the control operate where the risk actually occurs?

CISA released guidance on cyber deception techniques, including tripwires, honeytokens, and other forms of cyber decoys designed to identify malicious activity early in the intrusion lifecycle.

The value of these controls comes from where they are positioned. Many security programs still focus heavily on detection after an attacker reaches production systems, accesses sensitive information, or begins moving laterally through the environment. Decoys create opportunities to detect activity much earlier by placing indicators where legitimate users should rarely go.

Organizations adopting deception technologies should evaluate whether alerts trigger before an attacker reaches privileged systems or sensitive data. Early detection is most valuable when it creates time to respond before the intrusion progresses.

Source: @CISACyber

John Hammond published a walkthrough of a Steam zero-day vulnerability on Windows that allows a standard user to escalate privileges to SYSTEM. The demonstration reduced the attack path to a relatively small PowerShell-based proof of concept and highlighted how a consumer application can introduce risk on enterprise endpoints.

The example reminds security teams that they often focus on business applications while underestimating software that enters the environment through other channels. Consumer applications may not appear on lists of critical business systems, but they still operate on the same operating system, interact with the same security controls, and can affect the same enterprise assets.

Organizations should understand whether unmanaged or non-essential software installed on corporate devices can be leveraged to gain elevated privileges. The issue is not whether the application is intended for enterprise use. The issue is whether it creates a path to enterprise compromise.

Source: @_JohnHammond

NIST published a small-business primer supporting NIST SP 800-171A Revision 3 and announced an upcoming webinar focused on assessing security requirements for Controlled Unclassified Information (CUI).

The publication reinforces a challenge frequently encountered during compliance assessments. Written policies and documented procedures are necessary, but they are not the same as evidence that security activities are consistently performed. Organizations handling CUI are expected to show how they assess and validate requirements, not simply that they have documented them.

For smaller suppliers in particular, assessment maturity often becomes as important as policy maturity. A security requirement provides value only when the organization can demonstrate it is operating as intended.

Source: @NISTcyber

3. Internal Audit, IT Audit & Continuous Control Monitoring

Artificial intelligence, automation, and continuous monitoring are changing what organizations expect from audit and assurance functions. Traditional sampling and periodic reviews remain important, but they are increasingly being supplemented by questions about real-time visibility, control effectiveness, and the role audit should play before deploying new technologies. This week's posts explore those questions through AI-enabled workflows, continuous control monitoring, and audit teams' involvement in enterprise AI adoption.

AI Assurance highlighted a growing concern across regulated industries: many significant losses still originate from human error, convenience-driven workarounds, and weak process controls rather than highly sophisticated attacks. The analysis focused on customer-support workflows that can issue short-lived elevated tokens and warned that risks increase significantly when autonomous agents enter the same process.

The concern is not the agent itself. The concern is whether an existing workflow grants privileges that can be exercised faster than controls can evaluate, approve, or revoke them. Organizations planning agent deployments should identify any process that can issue permissions tied to payments, sensitive data, or identity-related actions, and confirm that effective controls exist before introducing automation.

Source: @gdprschemes

Shah Sheikh shared a SecurityWeek article examining the difference between traditional assessments and continuous control monitoring.

The article challenges a common assumption: that evidence collected during an audit or assessment remains representative of how a control operates months later. Point-in-time reviews provide valuable assurance, but they do not always reflect the current operating state of rapidly changing environments.

Continuous monitoring addresses a different question. Instead of asking whether a control operated during the last review cycle, it asks whether the control is functioning today. As technology environments become more dynamic, organizations may need both approaches: periodic assurance to assess design and governance, and continuous monitoring to validate ongoing effectiveness.

Source: @shah_sheikh

SiliconANGLE reported that Newell Brands is placing internal audit at the center of its AI adoption efforts.

The approach reflects a broader shift occurring across many organizations. Historically, audit teams often became involved after implementing a new technology. AI adoption is encouraging a different model, with audit participating earlier in governance discussions, control design reviews, and risk assessments before systems enter production.

The advantage of earlier involvement is straightforward. Risks identified during design are generally easier and less expensive to address than risks identified after deployment. Audit does not replace business ownership or technology governance, but it can help organizations evaluate whether the controls surrounding a new capability are appropriate before it becomes operational.

Source: @SiliconANGLE

4. Identity Management / IAM

Identity teams have spent years strengthening authentication, access management, and user governance. AI systems, service accounts, APIs, and machine identities are introducing a different challenge: how should organizations govern identities that act without direct human intervention? This week's posts examine that question through healthcare AI workloads, token-based authentication, and long-standing risks associated with service accounts. Together they highlight the growing importance of understanding who, or what, is acting inside the environment and what authority that identity carries.

AZGingerHacker highlighted a case study from Token Security, and AWS focused on AI systems that process protected health information (PHI). The discussion centered on the machine identities, service accounts, APIs, and workloads that allow those systems to operate.

The example reflects a broader shift occurring across identity programs. Organizations often maintain mature processes for governing employee and contractor access while giving less attention to the non-human identities that support applications and AI systems. Yet those identities frequently possess access to sensitive information and critical business functions.

An AI system's access to PHI is ultimately governed by the identities and permissions operating behind the service. Organizations should inventory those identities, understand what information they can access, and apply the same principles of least privilege, monitoring, and review that are expected for human users.

Source: @AZGingerHacker

CISA, in coordination with NIST and other agencies, published recommendations for protecting the tokens and assertions that support single sign-on, federation, and API-based access.

The guidance reflects how identity attacks continue to evolve. Many modern attacks do not require stealing a password if an attacker can obtain a valid token or authentication assertion. In those situations, traditional password controls may remain fully compliant even as access is compromised.

Organizations should evaluate how tokens are issued, protected, monitored, revoked, and validated throughout their environments. The question is no longer limited to whether credentials are secure. It increasingly includes whether the mechanisms that prove identity remain trustworthy after authentication.

Source: @CISACyber

Sean Metcalf shared guidance on Kerberoasting attacks targeting Active Directory accounts associated with Service Principal Names (SPNs). The discussion included practical recommendations such as removing SPNs from personal administrative accounts, rotating long-standing service account passwords, and reviewing service-account configurations.

Many identity teams recognize this underlying issue. Service accounts often remain in place for years because applications depend on them and changes carry operational risk. Over time, those accounts can accumulate privileges, outdated passwords, and limited oversight.

As organizations focus attention on AI identities and machine accounts, older identity risks have not disappeared. Service accounts remain attractive targets because they are often exempt from the governance processes applied to human users.

Source: @PyroTek3

5. Cyber Insurance

The cyber insurance market continues to grow, premiums remain competitive in many sectors, and coverage is more accessible than it was several years ago. The more important question for organizations is whether the controls, recovery capabilities, and governance processes behind the policy are keeping pace with the risks those policies are expected to address. This week's posts examine that question through underwriting practices, market growth, and the emerging intersection between cyber insurance and AI governance.

ObserveCo highlighted changes in the Singapore market, noting that cyber insurance premiums for many small businesses have declined while AI-related incidents continue to affect more organizations. The post also noted that foundational controls such as multi-factor authentication, offline backups, and patch management remain absent in many environments despite their importance to both cybersecurity and underwriting.

The observation reinforces a familiar challenge. Purchasing insurance and reducing risk are not the same activity. Competitive pricing may improve access to coverage, but the controls supporting the application often remain more important than the premium itself. Organizations should be able to demonstrate that foundational security controls are operating before relying on insurance as part of their response strategy.

Source: @1571keplerj

Market Size Info highlighted research from IMARC Group projecting significant growth in the European cyber insurance market over the coming decade.

The projected expansion reflects growing awareness of cyber risk and increased demand for coverage. It also raises a practical question for buyers. As the market grows, insurers are likely to continue refining underwriting expectations, evidence requirements, and claims reviews. Organizations that treat cyber insurance as a procurement exercise may overlook the operational reality that coverage increasingly relies on the quality of the controls supporting the policy.

Market growth can create additional options for buyers, but it does not reduce the need for demonstrable security, recovery, and governance practices.

Source: @marketsizeinfo

Cyber Insurance News reported findings from a Nationwide survey showing that a significant percentage of mid-market organizations purchase cyber insurance while simultaneously reporting limited AI governance, oversight, or formal controls.

This finding matters because AI-related risks increasingly intersect with multiple coverage areas, including cyber, privacy, professional liability, and regulatory exposure. As organizations introduce AI into business processes, insurers are becoming more interested in how those systems are governed, who owns the risk, and what controls are operating around their use.

AI adoption introduces questions that organizations may not have needed to answer in previous renewals. Can AI-related decisions be audited? Does a defined policy govern AI use? Who owns oversight responsibility? Can the organization demonstrate that the control framework is operating as intended?

Source: @CyberInsureNews

6. Data Protection

AI, automation, and rapidly growing data volumes are changing how organizations think about data protection. Traditional practices such as classification, retention, and access management remain important, but new questions are emerging: How quickly can organizations identify unauthorized changes to personal data? Can protection controls operate as fast as automated systems? Do governance models account for risks that did not exist a few years ago? This week's posts explore those questions through AI-enabled incidents, the financial impact of large-scale extortion events, and automated approaches to data protection.

hackerlogs highlighted reporting that Spain's data protection authority (AEPD) received what is believed to be its first GDPR Article 33 notification involving a personal-data breach allegedly executed with the assistance of an AI system. According to reporting referenced in the post, an individual used a widely known model to gain access to an application, alter personal data, and view invoice information. The investigation remains ongoing, and the affected organization has not disclosed details publicly.

The significance extends beyond a single incident. Many organizations structure privacy risk assessments around familiar categories such as phishing, malware, insider threats, or credential compromise. AI-assisted activity introduces different patterns of behavior, speed, and scale. As organizations evaluate privacy risks, they may need to consider whether existing scenarios adequately capture how automated systems could access, modify, or expose personal information.

A useful question for privacy and security teams is whether risk assessments, playbooks, and detection processes include scenarios involving AI-assisted or agent-assisted activity rather than focusing exclusively on traditional attack methods.

Source: @hackerlogs

Cyber Insurance News highlighted NetDiligence research showing a significant increase in ransomware payments exceeding $10 million.

While ransomware is often discussed as a cybersecurity issue, the growing scale of these events also has important implications for data protection and privacy governance. Large-scale incidents increasingly involve operational disruption, regulatory notification obligations, reputational consequences, and extensive reviews of affected personal information.

As attack costs and disclosure requirements continue to grow, organizations may need to evaluate whether recovery planning assumptions still align with current threat conditions. The discussion extends beyond restoring systems. It also includes understanding what information was affected, what notifications may be required, and how stakeholders will be informed when a significant event occurs.

Source: @CyberInsureNews

Cohesity shared guidance on automating data protection through Data Security Posture Management (DSPM), including object groups, automated rules, and AI-assisted administration.

The discussion reflects a broader challenge many organizations face. Data volumes continue to grow while information increasingly moves across cloud platforms, repositories, collaboration tools, and business applications. Manual approaches to classification and protection can become difficult to sustain when people and automated systems create, move, and modify data at scale.

Automation does not eliminate governance responsibilities, but it can help organizations apply controls more consistently. The effectiveness of those controls often depends on whether protection policies follow the data's characteristics rather than relying exclusively on manual tagging or user intervention.

Source: @Cohesity

7x. Enterprise Digital Risk Products

Trust relationships continue to expand across cloud platforms, identity systems, collaboration environments, and AI-enabled workflows. As they do, organizations face a practical challenge: how do you know that access granted months or years ago is still appropriate today? This week's posts examine that question through passkey enrollment workflows and privilege management inside Microsoft 365 environments. Both examples focus on a similar issue: access may appear legitimate long after the original reason for granting it has disappeared.

Swif highlighted reporting on attacks in which threat actors impersonate helpdesk personnel to convince users to re-enroll passkeys or authentication methods. Once the process is completed, attackers can register their own authentication factors and maintain persistent access while appearing to use legitimate credentials.

The example shifts attention from the authentication technology itself to the process surrounding it. Strong authentication may be functioning exactly as designed, yet the enrollment workflow can still become the point of compromise if attackers successfully manipulate users or support personnel.

Organizations should review how new authenticators are registered, who can authorize enrollment changes, and what monitoring exists around helpdesk-driven resets. Successful sign-ins are not always the most important event. Changes to authentication methods may provide earlier indicators that someone is altering a trusted account.

Source: @swif_ai

Guardian Digital focused on another form of accumulated risk: permissions that remain in place long after their original business purpose has ended. The post noted that Microsoft 365 environments can appear secure while still carrying years of inherited access through privileged Entra ID roles, OAuth and Microsoft Graph permissions, external sharing relationships, and Conditional Access exclusions.

The challenge is that permissions often persist quietly. They are not necessarily unauthorized, but they may no longer be necessary. Over time, these exceptions, exclusions, and elevated privileges create a larger access footprint than administrators intended.

Regular reviews of privileged roles, application permissions, external sharing configurations, and policy exceptions can help organizations identify access that remains active even though ownership or business justification has changed. Removing unnecessary trust relationships often reduces risk more effectively than adding new controls.

Source: @gdlinux

Closing Thoughts

This week's developments span different disciplines, but they point to a similar shift in how organizations think about risk.

Controls are no longer evaluated solely on whether they exist. Increasingly, they are evaluated on whether they can adapt to changing dependencies, support faster decision-making, govern automated activity, and remain effective as technology and business processes evolve.

Third-party relationships, AI-enabled systems, machine identities, recovery plans, privacy obligations, and enterprise platforms all introduce new points where authority, accountability, and visibility can become disconnected. In many cases, the underlying risk is not the technology itself. Risk emerges when ownership is unclear, assumptions no longer hold, or controls move more slowly than the surrounding environment.

A useful exercise before the next governance, risk, or audit review is to examine the organization's most important controls and ask three questions:

What does this control govern?

Who is accountable for it?

How do we know it is operating today?

The answers will often reveal gaps in ownership, accountability, and control long before they appear in a risk report.