The Trust Layer: The Part of Your Stack Nobody Audits

Security tooling has a name for almost everything. Code you wrote: SAST. Dependencies with known CVEs: SCA. Secrets in the repo: secret scanning. Running systems: CSPM, EDR, a whole alphabet. But look at what actually executed in the supply-chain incidents of the past few months, node-ipc in May, the AntV burst, the Miasma worm in June, and the entry point was none of those categories. It was the layer in between: the artifacts your tools obey without anyone reviewing them.

What the layer contains

Call it the trust layer: everything your project and your agents are about to trust, at the moment trust is granted.

• Lockfiles decide what gets installed, including aliases that can point a friendly name at a hostile package
• Install scripts execute before you run anything: npm lifecycle hooks, setup.py, build.rs
• Package-manager policy in the repo can switch defenses off for everyone who clones
• CI workflows hold tokens and decide what fork code can touch
• MCP configs declare which servers an agent loads and with what credentials
• Agent configuration, Claude Code settings, .cursorrules, AGENTS.md, shapes what an AI tool does with your repo open

The common property: these artifacts are obeyed, not reviewed. They execute or take effect at clone, at install, at session start, at merge. By the time a human looks at behavior, the trust decision already happened.

Why existing categories miss it

SCA asks whether your dependencies have known vulnerabilities, a different question from whether yesterday's publish of a clean package is malicious. SAST reads the code you wrote, not the workflow YAML that hands a token to a fork. And nothing in the traditional stack has an opinion about a SessionStart hook in a repo's agent settings, because that file format did not exist when those categories formed. The agent layer did not just add new tools; it added new artifacts that grant trust.

What defending it requires

Four properties, forced by the layer's shape. Before execution: checks must run at clone and pre-install, because that is when the decisions happen. Local: the layer includes credentials and private code; shipping it to a SaaS to evaluate trust is itself a trust decision. Deterministic: trust verdicts gate merges, and a gate that changes its answer between runs gets removed within a month. Verifiable: a tool that audits trust must be more auditable than what it audits, signed releases, SBOMs, open rules.

That is the design brief Aguara is built against: one signed binary, an open rule catalog versioned with it, offline by default, same input same verdict. Not a full SCA, deliberately; the category it serves is the one without a shelf, and the honest scope is written into the tool.

Name it to defend it

Categories matter because budgets, reviews, and checklists follow names. "Did anyone check the trust layer" is a question a team can ask in a release review, and mostly nobody asks it yet. The incidents of this spring were not exotic. They walked in through artifacts everyone ships and nobody reads. Start reading them, or let tooling do it, before they execute.