A Context Repository Is Not a Security Scanner

Recently, I have been experimenting with security scanners for Agent Skills.

This made me think about an important question.

What should a Context Repository do when another tool reviews a Skill?

At first, the answer may seem simple.

Run the scanner.

Store the result.

Reject anything unsafe.

But the more I explored this, the more I realized that the responsibility of a Context Repository is different.

A Context Repository is not a security scanner.

And I think that is a good thing.

Different tools solve different problems

The ecosystem around AI agents is growing quickly.

We now have:

• security scanners
• package managers
• registries
• synchronization tools
• runtime policy systems
• agent frameworks

Many of these tools work with similar artifacts.

Skills.

Prompts.

Agent configurations.

MCP servers.

Because they touch the same files, they can look like alternatives.

I don’t think they are.

They solve different problems.

A security scanner asks:

Does this Skill contain suspicious or dangerous behavior?

A package manager asks:

How should this Skill be installed and resolved?

A registry asks:

How should this Skill be published and discovered?

A runtime policy system asks:

What should this Skill be allowed to do while it is running?

A Context Repository asks something else.

How should this knowledge be owned, reviewed, connected, maintained, and trusted inside a repository?

These responsibilities overlap.

But they are not the same.

What a security scanner knows

A security scanner can inspect things that a Context Repository should not try to understand by itself.

For example:

• suspicious shell commands
• hidden executable code
• unsafe downloads
• data exfiltration patterns
• prompt injection
• dangerous tool usage
• malicious dependencies

These are specialized security questions.

They require specialized rules, analyzers, and threat models.

I don’t want Renma to become another security scanner.

That would create several problems.

Renma would need to maintain security detection rules.

It would need to understand many programming languages.

It would need to keep up with new attack patterns.

It would also need to decide whether every security finding was correct.

That is not the problem Renma is trying to solve.

Security findings should belong to security tools.

A scanner result is not enough

However, simply running a scanner is also not enough.

Imagine a report says:

SAFE

What does that actually mean?

Which Skill was scanned?

Which files were included?

Were executable files analyzed?

Which analyzers were enabled?

Did any analyzer fail?

Was network-based analysis disabled?

Was the repository modified after the scan?

Were findings suppressed?

Does the report still describe the current version of the Skill?

Without these answers, SAFE has very little meaning.

This was one of the most important things I learned from the experiments.

The final verdict is only one part of the evidence.

Execution and completeness are different

A scanner may finish successfully.

That does not necessarily mean every expected analysis was performed.

For example, a scanner may report:

exit status: 0
findings: 0
coverage: 100%

This looks reassuring.

But perhaps executable code was classified as documentation.

Perhaps an optional analyzer was disabled.

Perhaps the scanner inspected every file it selected, but selected only part of the Skill.

The command completed.

The review may still be incomplete.

I think a Context Repository needs to keep these concepts separate.

producer execution
reviewed scope
analysis completeness
native assessment
governance satisfaction

They are related.

But they are not interchangeable.

Findings belong to the producer

Another important boundary is the ownership of findings.

Suppose a scanner reports a suspicious pattern.

Renma should not silently convert it into a Renma diagnostic.

The scanner has its own:

• rule identifiers
• severity model
• confidence model
• risk score
• suppression behavior
• analyzer version
• interpretation of safety

Those semantics belong to the scanner.

Renma does not need to become the final judge of whether the finding is correct.

Instead, Renma can preserve the evidence that the external review happened.

For example:

producer: security-scanner
version: 1.2.3
subject: skill.release-prep
reviewed revision: abc123
profile: local-static
result: caution
report digest: ...

The original report remains the source of truth for the security assessment.

Renma only connects that assessment to the repository’s governance model.

Governance satisfaction belongs to the repository

A Context Repository knows things that a standalone scanner usually does not.

It knows:

• the canonical Skill identity
• the owner
• the lifecycle state
• the expected review policy
• the repository revision
• the dependency graph
• the entrypoint
• the required Context Assets
• the freshness expectation

This allows the repository to ask a different question.

Not:

Is this Skill safe?

But:

Has this Skill received the external review required by our governance policy?

That may depend on several conditions.

correct producer
+ acceptable version
+ required analysis profile
+ exact subject
+ sufficient reviewed scope
+ complete execution
+ acceptable native outcome
+ current repository revision
= review requirement satisfied

This is not security analysis.

It is governance.

Suppression is also evidence

Security scanners sometimes produce false positives.

That is normal.

A repository may decide to suppress a finding after review.

But suppression should not make the finding disappear from history.

We should still be able to understand:

• what was found
• why it was suppressed
• which exact finding was suppressed
• who reviewed it
• whether the source changed afterward
• whether the suppression still applies

This is another place where a Context Repository can help.

The scanner owns the suppression mechanism.

The repository can own the governance around that decision.

A suppression without identity or traceability is just silence.

A reviewed suppression is evidence.

The same idea applies beyond security

Security scanners are only one example.

The same model can apply to many external producers.

A documentation checker may review clarity.

A policy checker may review compliance.

A test generator may produce validation evidence.

A package manager may resolve dependencies.

A registry may verify publication requirements.

A runtime system may enforce permissions.

I don’t think a Context Repository should replace any of these tools.

Instead, it can provide the structure that connects their evidence to maintained knowledge.

Context Repository
    |
    +-- Security review
    |
    +-- Policy review
    |
    +-- Dependency resolution
    |
    +-- Publication evidence
    |
    +-- Runtime enforcement

Each tool keeps its own semantics.

The repository keeps the relationships.

Where Renma should stop

While building Renma, I often think about what it should not do.

I don’t want it to become:

• an LLM runtime
• a package registry
• a security scanner
• an agent framework
• a policy enforcement gateway
• a universal AI platform

Trying to own every layer would make the project larger.

But it would not necessarily make it more useful.

I want Renma to stay focused on repository-level governance.

What exists?

Who owns it?

How is it connected?

Is it ready to use?

What changed?

What evidence supports its current state?

I believe that boundary will make it easier to integrate with better tools as they appear.

Tools will change

The security scanners available today will change.

Some will improve.

Some will disappear.

New ones will appear.

The same will happen to package managers, registries, and agent runtimes.

A Context Repository should not depend on one tool becoming the permanent winner.

What should remain stable is the repository’s ability to describe:

• what was reviewed
• who reviewed it
• how it was reviewed
• which version was reviewed
• what the result was
• whether that evidence is still current

The producer may change.

The need for governance evidence will remain.

A Context Repository is a connection layer

I used to think mostly about Context Repositories as places to organize reusable knowledge.

I still believe that is their most important role.

But now I see another responsibility.

A Context Repository can become the layer that connects maintained knowledge with the tools that inspect, distribute, and execute it.

Not by absorbing those tools.

Not by replacing them.

But by giving their results a clear subject, scope, history, and meaning inside the repository.

Security scanners should find security problems.

Registries should distribute artifacts.

Package managers should resolve dependencies.

Runtime systems should enforce behavior.

A Context Repository should help us understand whether the knowledge we depend on is owned, reviewed, connected, and supported by trustworthy evidence.

Maybe that is where it fits best.

Not as the tool that does everything.

But as the place where everything becomes understandable.