A useful way to think about that is through three words:
Perception. Context. Permission.
In this frame, perception is what someone believes they are seeing. Context is the surrounding situation that makes the thing feel normal, safe, or expected. Permission is the moment the next step gets allowed either by a person, a process, or a machine.
This is not just a communication model. It is also a useful way to think about how attacks work because, in a very real sense, almost everything the brain does passes through some version of perception, context, and permission. The brain does not simply record the world like a camera. It interprets, predicts, filters, and prioritizes. Modern neuroscience often describes perception as an active process shaped by expectations, prior experience, and current goals, rather than a pure bottom-up readout of reality. Predictive processing research and attention research both support that broader picture.
That matters because attackers do not always need to "beat" a person or a system. Often they only need to guide interpretation. If they can make something look familiar, place it inside a believable setting, and get one critical step approved, they can inherit trust that was never meant for them.
What PCP Means in This Context
Let's make it simple.
Perception means: "This looks legitimate."
Context means: "This is happening in a situation where it makes sense."
Permission means: "I, or my environment, will allow the next action."
In a cyber incident, that next action might be:
- Opening a meeting invite
- Installing a "fix"
- Approving a login
- Trusting a signed artifact
- Pulling a package from a familiar registry
- Running a GitHub Action because it belongs to a known vendor
- Accepting a token or workflow because it came from an approved path
That is why so many modern attacks do not begin with brute force. They begin with alignment. The attacker aligns the target's interpretation of events with the attacker's desired outcome.
The Psychology Behind It
The brain is constantly making fast judgments about what matters, what is safe, and what can be ignored. That is not a flaw. That is how we function. If the brain had to deeply verify every email, meeting invite, package update, or colleague interaction from first principles, normal life would grind to a halt.
Instead, the brain relies on shortcuts.
It uses prior expectations to shape present perception. It uses context to decide what interpretation is most likely. It uses attention to filter what gets processed deeply and what stays in the background. Predictive-processing models describe the brain as continuously generating expectations about the world and updating those expectations based on incoming signals. Attention then helps assign weight to what seems important or surprising.
That means perception is never isolated. It is always embedded in context.
A message from a stranger asking for credentials feels suspicious in one setting. The same message, inside the middle of a known support workflow, from what appears to be a trusted colleague, during an urgent outage, may feel much more plausible. The raw content may barely change. The context does the heavy lifting.
And once context stabilizes the interpretation, the brain often grants what we might call permission. Not necessarily conscious permission. Often it is more like cognitive acceptance. The next step feels normal enough to proceed. The warning systems stay quiet. The action passes through.
That is why the same person who would never click a random malicious link may still install a fake conferencing fix during what looks like a normal work meeting. The issue is not intelligence. The issue is that intelligence is always operating inside a frame.
Everything in the Brain Passes Through This Filter
If you zoom out, a huge amount of cognition works this way.
You do not just perceive. You perceive as something. You do not just notice. You notice within a situation. You do not just act. You act when the brain has, explicitly or implicitly, judged the action acceptable enough to move forward.
That is why these three words matter beyond cybersecurity.
Perception shapes meaning. Context shapes perception. Permission shapes action.
The brain uses constant triage. It asks - usually outside conscious awareness:
- What am I looking at?
- What kind of situation is this?
- What response is appropriate here?
That structure is all over everyday life. It is also all over manipulation, persuasion, fraud, and intrusion.
In security, that final transition - from interpretation to allowed action - is where the damage usually begins.
Why This Matters So Much in Software Supply-Chain Attacks
Supply-chain attacks are frightening because they attack trust at scale.
A normal phishing email may compromise one user. A successful supply-chain attack can compromise many organizations because it rides along channels that are supposed to be trusted already: package ecosystems, signed releases, CI/CD, update mechanisms, build automation, and developer tooling.
That makes PCP especially useful here.
In classic security language, defenders talk about initial access, credential theft, lateral movement, execution, persistence, and exfiltration. All true. But before those stages, there is usually a quieter sequence:
Something is made to look legitimate. It appears inside a trusted setting. A person or system allows execution or access.
That is PCP.
The Axios Incident Through the PCP Lens
The recent Axios compromise is one of the clearest examples of this pattern.
According to the Axios maintainer's postmortem and multiple security analyses, two malicious versions - axios@1.14.1 and axios@0.30.4 - were published to npm on March 31, 2026, through a compromised maintainer account. Those releases added plain-crypto-js@4.2.1, a typosquatted dependency that executed a malicious install-time payload and delivered a cross-platform RAT affecting macOS, Windows, and Linux. The malicious releases were live for roughly three hours before removal.
What makes the Axios case especially instructive is that the story did not start in npm. It started with social engineering.
The maintainer's account and follow-up reporting describe a highly convincing lure involving a fake company presence, a realistic Slack workspace, and a fake Microsoft Teams troubleshooting flow. That flow appears to have pushed the maintainer toward installing malware disguised as a technical fix. Security reporting says the attacker then used the resulting access to publish the poisoned Axios versions directly from the compromised maintainer path rather than through the project's usual trusted publishing route.
Seen through PCP, the attack becomes easier to understand.
Perception in Axios: The attacker did not present obvious malware. They presented a believable professional interaction. The setup looked like work. The people looked real. The tools looked familiar. The troubleshooting step looked routine. The target's perception was shaped so that the event did not feel like an intrusion. It felt like collaboration.
Context in Axios: The entire deception lived inside a context that lowered suspicion - chat, meetings, technical troubleshooting, professional identity, ordinary workflow. Context is what transforms an odd action into a reasonable one. Outside that frame, installing a mystery "fix" would raise alarms. Inside that frame, it can feel like a normal step in getting a meeting to work.
Permission in Axios: Permission was the pivotal moment. The maintainer installed the supposed fix. That action gave the attacker the access they needed to reach the npm publishing path. Once that trust transfer happened, the attacker no longer needed to persuade downstream developers one by one. The ecosystem did that work automatically by trusting a package published under a legitimate maintainer account.
This is the deeper lesson of Axios: the package was not the first thing compromised. Trust was.
The Trivy and Checkmarx-Related Activity Through the Same Lens
The same pattern shows up in the recent TeamPCP-linked supply-chain activity.
Microsoft says the campaign attributed to the actor identifying as TeamPCP began with the Trivy supply-chain attack and later expanded to additional frameworks, including Checkmarx KICS and LiteLLM. Other security reporting describes the campaign as abusing stolen CI/CD secrets, signing material, and trusted automation paths to widen downstream impact across software environments.
That point matters. These incidents were not dangerous only because code changed. They were dangerous because the code changed inside places organizations are trained to trust.
Perception in TeamPCP-related activity: The malicious elements looked like legitimate parts of the development and security toolchain - workflows, actions, releases, scanner behavior, signed or trusted artifacts. To a downstream team, the initial impression was often not "intrusion," but "normal software movement."
Context in TeamPCP-related activity: The context was ideal for abuse: CI/CD, developer tooling, security scanners, GitHub Actions, package and release infrastructure. These are environments where automation is expected and where teams are incentivized to reduce friction, not increase it. In that kind of environment, trust becomes operational. It is embedded in the workflow itself.
Permission in TeamPCP-related activity: Permission came in the form of valid tokens, inherited trust, compromised signing paths, approved workflows, and automatic execution. Once those channels were under attacker control, systems continued doing what they were designed to do: run trusted processes. The problem was that the trust boundary had already been crossed.
This is why supply-chain attacks are so powerful. They do not always force entry. They reuse legitimacy.
Why Experienced People Still Fall for This
It is tempting to explain these incidents by saying someone was careless. That is too shallow.
Experienced engineers, maintainers, and security professionals are not immune because these attacks are not built on stupidity. They are built on human normalcy.
The brain is optimized for efficient functioning under familiar conditions. In ordinary work life, most interactions are legitimate. Most updates are real. Most meeting invites are not traps. Most package changes are not hostile. So the mind builds efficient expectations. That is adaptive. Attackers exploit that adaptiveness.
The more polished the deception, the more it can borrow from the target's real world: recognizable tools, familiar workflows, plausible urgency, believable social proof, technical language, legitimate channels, professional rhythm. At that point, the victim is not ignoring red flags as much as operating within a frame that has already been engineered.
The Bridge Between Psychology and Security
Security people sometimes separate "human issues" from "technical issues." That split is useful for organization charts, but it is often misleading in practice.
A human being authorizes the laptop. A human being approves the workflow. A human being maintains the package. A human being trusts the message. Then the machine takes over and scales the consequence.
That is why PCP is such a useful lens. It reminds us that a supply-chain attack is often both a psychological event and a technical one.
First the attacker shapes meaning. Then the attacker uses that meaning to cross a trust boundary. Then the systems amplify the result.
What Defenders Can Learn from This
The big takeaway is not just "be more careful." That is too vague to be useful.
The real lesson is that organizations need defenses at all three layers.
Defending perception means helping people spot things that merely look right. Better skepticism around identity verification, unusual troubleshooting flows, side-channel downloads, and requests that arrive dressed in familiar tooling.
Defending context means treating "normal workflow" as a possible attack surface. Chat, meetings, package publishing, CI/CD, and release engineering are no longer just productivity channels. They are security boundaries.
Defending permission is where technical controls matter most: hardened publishing paths, least privilege, scoped tokens, short-lived credentials, approval boundaries, isolated build systems, provenance checks, and monitoring around trusted workflows. The more difficult it is for one compromised action to inherit broad trust, the less devastating the attack becomes.
The Larger Point
Attackers are not just trying to trick systems. They are trying to shape behavior. They do that by changing the context around a person until a different action feels normal. A request that would look suspicious on its own can feel reasonable inside the right setting - a meeting invite, a support conversation, a trusted workflow, a package update, a security alert, a teammate asking for help.
The goal is not only to fool the eye, but to shift the frame. Once the frame changes, behavior changes with it. The victim becomes more likely to click, install, approve, trust, or proceed - not because they suddenly stopped thinking, but because the situation has been engineered to make that choice feel appropriate.
The brain interprets. The environment frames. The action gets allowed.
That sequence sits underneath persuasion, fraud, social engineering, and many of the most damaging cyber intrusions. The recent Axios compromise and the TeamPCP-related Trivy and Checkmarx activity show what happens when attackers stop trying to look malicious and start trying to look normal.
The most dangerous attacks often do not begin with something that feels dangerous. They begin with something that fits your expectations. Something that belongs in the setting. Something that earns one small yes.
And once that yes is granted, everything downstream may still behave exactly as designed.
Whether the name "TeamPCP" is related or not, the pattern behind it is hard to ignore.
There is no confirmed evidence that the name stands for Perception, Context, Permission. It could be coincidence. It could be an internal reference. It could mean something completely unrelated. But the overlap is difficult to dismiss. If you step back and look at how these attacks actually work, they follow that exact structure with uncomfortable precision. They shape what the target sees, embed themselves in environments that feel normal, and move through trust paths that allow execution without resistance. In other words, they control perception, choose the context, and obtain permission.
And here is where it gets interesting. Groups like this rarely pick names at random. Names are often chosen to signal identity, reflect internal thinking, or carry meaning within the group itself. Sometimes that meaning is obvious, sometimes hidden, sometimes only understood by those behind it. That does not prove anything about this specific case, but it does make the coincidence harder to ignore. Whether intentional or accidental, the name mirrors the mechanism, and that is what makes it useful. It highlights something defenders often overlook: these attacks are not just technical. They are about how trust is interpreted, transferred, and acted upon. The code is only the final stage. Before that, something looks legitimate, then it feels like it belongs, then it is allowed. After that, everything else unfolds naturally. So maybe the name means nothing. Or maybe it says everything.