What makes a security claim inspectable?
Source location, provenance, deterministic signals, threat context, integrity data, and the limits of the observation should remain attached to the claim.
Research
Make trust measurable.
Aegis treats “safe,” “fixed,” and “verified” as claims that need observable support. Research is where we define how those claims should be tested, reproduced, and challenged.
What counts as independent checking?
A verifier must remain distinct from the system that proposed the security-sensitive action, and deterministic checks must not be replaced by model agreement.
Did the patch close the path?
Patch acceptance is not the target metric. The stronger question is whether the original failure stops reproducing without introducing a new failure.
Aegis deliberately represents different forms of evidence as different records. Deterministic scanner output is not model review. Model review is not independent verification. Controlled reproduction is not authorization to change code. A successful patch application is not post-fix proof.
Fail-closed interpretation
Research outputs should make uncertainty visible. If a required check cannot run, the correct result is not an optimistic default. This is why Aegis distinguishes VERIFIED, PARTIAL, and FAILED rather than collapsing all non-errors into success.
Reproducibility over leaderboard theater
When Aegis publishes future benchmark or evaluation work, methodology should state versions, environments, prompts where relevant, deterministic fixtures, repetition strategy, and uncertainty. No public benchmark or leaderboard is claimed on this website today.
Secure-remediation correctness
How often does an automatically proposed security patch truly remove the vulnerable behavior rather than move it, hide it, over-restrict the feature, or introduce a regression?
Evidence sufficiency
Which combinations of static evidence, project tests, threat context, controlled reproduction, and independent review are sufficient for different classes of security claim?
Intent–action alignment
As software agents gain broader tool access, how should a trust layer reason about whether a requested action is necessary for the stated task, within authorized scope, and reversible if it fails?
Persistent security memory
How can a system retain useful project security history without turning uncertain or superseded conclusions into permanent “facts”?
Policy sufficiency
What evidence should be required before a security-sensitive change is allowed, sent to review, or blocked—and how should that requirement vary by risk and context?
Research should be inspectable.
The current implementation, fixtures, security model, and release gate are available in the public repository.