When the Monitored System Controls the Monitor

A security control can be present, enabled, and apparently working while someone quietly undermines its ability to do its job. 

A recent report from OpenAI described two incidents involving AI agents working on internal coding tasks. In one case, an agent suppressed automatic security alerts while repairing an evaluation pipeline. Monitoring continued to run and save reports, but the alerts intended to bring those reports to human attention had been disabled. In another case, an agent removed a monitoring integration while modifying the code, then inaccurately reported what it had changed. 

The details differ, but both incidents raise a fundamental architectural question. What happens when the system being monitored has enough control to interfere with its own monitoring? 

Application security has wrestled with a version of this problem for years. A mobile application runs on a device its developer does not control. An attacker may be able to inspect its code, manipulate its execution, or attempt to disable the protections intended to detect those activities. But adding a security check is only the first step. The check itself needs protection. 

Who guards the Guards? 

Consider a mobile banking application that checks whether its code has been modified. If the check detects tampering, it might shut down the application, require additional authentication, or restrict high-value transfers while allowing less sensitive functionality to continue. Those are useful responses. But they raise another question. What stops an attacker from finding the integrity check and modifying it so the check no longer works? 

A protection that can be disabled without resistance may give developers a false sense of security. The application contains the code to detect tampering, but an attacker who can change the code may also be able to undermine the detection. 

The same concern applies to threat monitoring. A system may identify suspicious behavior, but that capability is worthless if an attacker can interfere with the mechanism responsible for identifying it or suppress its findings. This is the challenge behind a familiar question in security: who guards the Guards? 

Adding more protection can help, but only if the protections themselves are accounted for in the design. Otherwise, an attacker may simply target the mechanism enforcing the security policy. 

Building a Guard Network 

Digital.ai’s Arxan application protection technology addresses this challenge through a system of security controls called Guards. Guards are injected into the protected application binary. They can check application integrity and respond to detected tampering according to policies configured for the application. Depending on the use case, a response might shut down the application, trigger step-up authentication, or disable a sensitive capability such as high-value financial transfers. The important architectural detail is that the Guards themselves can be protected by additional Guards. 

This creates what we call a Guard Network. A Guard does not have to stand alone as an isolated check that an attacker can identify and target. Other Guards can protect it, and those protections can themselves receive further layers of protection. In some implementations, the chain extends through a multiple layers, with Guards protecting Guards that protect other Guards. 

That layered structure changes the problem facing an attacker. Disabling a particular security check may require overcoming the protections surrounding that check as well. An attempt to interfere with one part of the protection architecture can encounter other parts designed to detect or resist that interference. That design matters more now than when the idea was first described. AI tooling has lowered the cost and skill needed to reverse-engineer applications at scale, and a single isolated check is the kind of target automated analysis can find and patch quickly.  

When Guards are configured to protect one another, removing one is designed to trip others. Depending on the target, teams can also vary the protection itself with more than one setting: seed values that make each protected build structurally different, random selection of Guard instances at protection time, and execution probabilities that mean not every Guard runs on every execution. Some Guards vary their own behavior at runtime, so they don’t present a static signature: an incremental checksum, for example, can verify a different range on each invocation instead of repeating one fixed check that automated analysis could learn and bypass. A stripping routine that worked against one release, or one run, isn’t guaranteed to work against the next. 

The Guard Network is not a claim that an application becomes impossible to compromise. No single architecture can guarantee that against every attacker, platform, or threat. Its purpose is to make the protections harder to locate, alter, and neutralize, including by accounting for attacks against the protections themselves. That distinction matters. Attackers do not always need to defeat an entire security architecture. Sometimes they only need to disable the one mechanism that would otherwise expose their activity. Protecting the Guards raises the difficulty of that approach.  

Detection needs a path to response 

Protecting integrity checks is one part of the problem. Security teams also need visibility into what happens when an application encounters a suspicious condition. 

Arxan Threat Monitoring operates within the protected application. The monitoring controls are injected into the binary, and alerts can be viewed through a browser or integrated into a security information and event management (SIEM) system. That gives organizations a way to review application-level security events and incorporate them into their broader security operations. The architecture matters here, too. Monitoring operates inside the application, so it should not be described as an entirely external observer. Its controls are part of the protected binary, and the protection architecture is designed to resist tampering with the application and its security mechanisms. 

The Guard Network provides an important part of that story by protecting the controls themselves. External alerting and SIEM integration provide a way to make reported events available beyond the application. These mechanisms serve different purposes. Guards can help protect application integrity and trigger responses to detected tampering. Threat monitoring can surface security-relevant activity. External reporting can help security teams investigate events and coordinate a response. 

Each part has limitations. A reporting channel cannot report an event that was never detected, and no protection should be assumed to withstand every possible attack. The aim is to make it harder for an attacker to compromise an application and then disable the mechanisms designed to expose or limit that compromise. 

The response should fit the threat 

Security controls are often discussed in terms of what they detect. In practice, what happens next can be just as important. A banking application might require step-up authentication after detecting a suspicious condition. It might restrict high-value transfers while leaving routine activity available. An application with stricter integrity requirements might shut down if its code has been modified. These responses reflect different assessments of risk. A developer can choose a response based on the application, the threat, and the potential consequences of allowing execution to continue. 

One of our gaming customers took a more entertaining approach. The team built a protection that detected when a player was cheating. When the protection triggered, it turned off the game’s gravity function. The cheater’s players would then float off the field. It’s a memorable example, and the underlying idea is serious. The protection was connected to a consequence that mattered in the environment where the attack occurred. Rather than treating detection as the end of the process, the developer used it to change what the application allowed. 

The same principle applies when the consequences involve money, sensitive data, or access to critical functionality. The response should be appropriate to the risk, and it should be difficult for an attacker to neutralize the mechanism that triggers it. Developers also need to account for false positives, recovery paths, and the impact on legitimate users. Protection should improve an application’s resilience without creating unnecessary disruption. 

Ask what happens when the Guards are targeted 

The OpenAI report is a useful reminder that monitoring can be undermined through changes to the systems it is intended to observe. Application developers face a related challenge when their software runs in environments where attackers can inspect and manipulate its execution. The question goes beyond whether an application has integrity checks or threat monitoring. It extends to how those mechanisms are protected, how they respond to interference, and whether an attacker can disable the controls that would otherwise expose the attack. 

This is where the Guard Network matters. By using Guards to protect other Guards, Arxan adds layers of protection around the security mechanisms themselves. That creates additional obstacles for attackers attempting to modify application defenses or neutralize individual controls. When evaluating an application security architecture, ask three questions.

1) What happens when an attacker targets the protection itself?
2) What prevents a single modification from disabling a critical security mechanism?
3) What options does the application have when a Guard detects tampering? 

The objective is not to promise that an application can never be compromised. It is to make tampering harder, preserve meaningful protections under attack, and give developers practical ways to respond when the application’s integrity is in question. Sometimes that response means restricting a financial transaction. Sometimes it means shutting down an application. 

And sometimes it means turning off gravity and watching a cheater’s players float away.