An unfamiliar program runs on a developer workstation, accesses stored credentials, and connects to an external server. Its behavior triggers an endpoint detection and response (EDR) alert, leaving an analyst to answer two questions: Is the code malicious, and what has it already done?
Generative AI can make that assessment harder by helping both attackers and developers produce unfamiliar code. Attackers can use it to write and revise malicious code, while developers use it to generate legitimate scripts and applications. Security teams must assess unfamiliar code from both sources without treating novelty as evidence of danger.
When that code runs with access to credentials or deployment systems, waiting for suspicious behavior can leave teams investigating exposure after the fact. The challenge is deciding what to check and restrict before execution, and what still requires runtime monitoring and analyst judgment.
Unfamiliar Code Adds to Analyst Workloads
Alert volume is often framed as a staffing problem. It is also a decision problem: Cases that require manual review consume analyst time as teams determine whether to contain the activity, permit it to continue, or escalate the investigation.
Someone has to determine what happened, what the artifact could do, and whether containment is justified. A suspicious file on an isolated test machine creates one level of urgency. The same file running in a build environment with access to signing keys, cloud credentials, or deployment rights demands deeper investigation.
AI can help attackers produce variants of malicious code, complicating checks that depend on previously identified files or signatures. But a new file hash does not necessarily mean a new attack technique. Behavioral detection remains important because different files can perform the same malicious actions.
The workload depends on how often unfamiliar code triggers alerts that automated controls cannot resolve.
Risk Scores Need Enforcement Rules
Probabilistic scoring is useful because real environments are messy. Signals are incomplete, behavior changes by context, and attackers create ambiguity on purpose. A score can help prioritize what deserves attention first.
A risk score becomes a weak basis for enforcement when organizations have not defined what the score should trigger. Policies should specify when to block activity, restrict permissions, or require review, taking account of the system involved and the access available to the code.
Organizations should be able to explain which rule, evidence, and environmental context led to an allow or block decision. Comparable cases should receive comparable treatment, while documented exceptions should account for legitimate differences in risk.
After Execution, the Investigation Expands
Once suspicious code runs, an investigation must establish both what the code is and what it did. Analysts may need to determine whether it accessed credentials, established a way to remain active, communicated with attacker-controlled systems, or affected other machines. Even when no compromise is found, that work consumes time.
Development workflows can extend the exposure. A package’s installation script may run with the permissions of the account installing it. AI-generated scripts can also run under privileged service accounts, giving unreviewed code access to credentials or deployment systems.
Detection and containment can limit an attack, but analysts may still need to establish what happened before containment. Earlier checks can complement those capabilities by identifying policy violations before code reaches sensitive systems.
Check Code and Limit Access Before Execution
Start with workflows that introduce or execute unfamiliar code, including downloads, AI coding agents, package installations, and continuous integration and delivery (CI/CD) pipelines. Review which accounts launch that code and whether their permissions exceed what the task requires.
Before unfamiliar code runs in a production or privileged environment, organizations can check its source, review its contents, and, where appropriate, test it in an isolated environment. Application controls can restrict what is allowed to run, while limited permissions can reduce what approved code can access. These measures can identify or limit some risks, but they cannot establish every action the code may take at runtime.
Runtime monitoring remains necessary because some malicious behavior becomes apparent only during execution. Earlier checks and execution restrictions can complement EDR by blocking identifiable policy violations and giving analysts more context. Teams should measure whether those controls reduce investigation time without creating excessive false blocks or delaying legitimate work.
