Agentix Lite Sentinel v0.8.2: Safer Deployment, Better Shadow Visibility, and ARM64 MCP Builds

Agentix Lite Sentinel v0.8.2 is now merged into "main".

https://www.npmjs.com/package/agentixlite/v/0.8.2

Thank you for your support! Every test, every bit of feedback, and every conversation helps move this project forward.
https://www.npmjs.com/package/sentinel-ir-mcp/v/0.3.0

This release is not about adding more autonomous behavior. It is about making the existing security core safer to deploy, easier to inspect, and more predictable across Linux architectures.

Here is what changed, explained in three reading levels.

The 30-second update

Version 0.8.2 brings four main improvements:

Safer nftables reconciliation: the installer and systemd preflight now share a fail-closed helper. It validates existing Agentix firewall structures before changing them and refuses to touch unidentified rules.
Better Shadow Observer diagnostics: more reliable handling of corrupted or ambiguous samples, clearer systemd errors, restart and resource reporting, and more detailed firewall drop information.
Explicit MCP enforcement status: the gateway reports whether automatic enforcement is enabled. Missing status information is treated as unknown, not guessed.
AMD64 and ARM64 builds: the Go MCP gateway now has architecture-aware Linux binaries. CI checks reproducibility for both gateway architectures and both native-validator architectures.

The Python security core remains the authoritative decision engine. The MCP interfaces remain read-only, and automatic enforcement is still disabled by default.

The goal of v0.8.2: improve operational safety without moving the security boundary.

The two-minute explanation for everyone else

Imagine that Agentix is a security guard working at the entrance to a building.

It needs to observe activity, keep records, and work with the building's existing security system. But it must not accidentally remove someone else's safety equipment while updating its own.

That is the idea behind the main changes.

A more careful firewall installer

Previously, the difficult part was not simply creating firewall rules. It was safely dealing with a firewall table that might already exist.

The new reconciliation helper checks the existing Agentix table, required IPv4 and IPv6 sets, chain configuration, and rules.

If it finds an unexpected rule, an incorrect chain, a missing set, or cannot inspect the existing table, it stops instead of assuming everything is safe.

It only replaces the two validated Agentix-owned chains. The blacklist sets and their contents are preserved.

A better observer, not another autonomous agent

The Shadow Observer is designed to watch a running host without changing its configuration or firewall.

It collects information such as:

Agentix runtime state and event counters.
Firewall and ingress drops.
Database and WAL file sizes.
systemd service state and restart counts.
Process memory and CPU usage.
Host memory and load.
Local MCP health.

It also checks whether the collected data is trustworthy. Corrupted records, duplicate timestamps, unexplained gaps, inconsistent counters, and mixed Agentix versions can now become visible anomalies.

The observer is a recorder and diagnostic tool. It does not decide to ban an address or turn on enforcement.

More honest MCP status

There is a difference between:

enforcement is disabled;
enforcement is enabled;
the available status does not tell us.

Version 0.8.2 makes that distinction explicit.

That may sound like a small change, but security software should never turn missing information into a confident assumption.

More Linux architectures

The Go MCP gateway now has separate Linux AMD64 and ARM64 binaries. The installer selects the appropriate binary and installs it behind an architecture-neutral executable path.

The optional native event validator also has reproducible builds for both architectures.

One limitation remains: the npm package is still Linux x64 only. ARM64 support in the installer-managed binaries does not automatically make the npm package ARM64-compatible.

The eight-minute technical section

3.1 Fail-closed nftables reconciliation

The central addition is:

"tools/nft-reconcile.sh"

Both the installer and the systemd nftables preflight use this shared helper.

The important behavior is that an inspection failure is not interpreted as proof that the Agentix table is missing.

A simplified example of the safety check:

if ! table_listing=$("$NFT" list tables 2>&1); then
echo "unable to inspect existing Agentix table: $table_listing" >&2
exit 1
fi

When the table already exists, the helper validates the required sets and chains.

It checks:

IPv4 and IPv6 set types and timeout flags.
Expected chain hooks.
Expected priority and policy.
Whether every existing rule is recognized as Agentix-managed.

Unknown rules cause reconciliation to stop:

if [[ -n "$unexpected" ]]; then
echo "Refusing to replace $name: unmanaged rules detected:" >&2
echo "$unexpected" >&2
return 1
fi

Only after validation does the helper prepare and apply the limited changes:

"$NFT" -c -f "$batch"
"$NFT" -f "$batch"

The first command validates the batch. The second applies it.

The helper does not flush the blacklist sets or delete the whole Agentix table.

What did we test?

The Python regression suite uses a fake "nft" executable so that different firewall states can be reproduced safely.

The tests cover:

First installation when the Agentix table is absent.
Reconciliation when the table already exists.
Missing required sets.
Incorrect chain hooks.
Unmanaged rules.
Permission errors while listing tables.
Repeated execution and idempotency.
Shared helper usage by the installer and systemd preflight.

This is useful coverage of the helper's decision logic. It is not a substitute for testing against a real Linux kernel and real nftables state.

Source: ""tests/test_nft_reconcile.py"" (https://gitlab.com/jakubrojicek11/agentixlite/-/blob/68f6d33527a34cfde1dc85b7c1bdcdb2e51acff6/tests/test_nft_reconcile.py)

3.2 Shadow Observer: better data integrity and diagnostics

The main implementation is:

"tools/shadow_observe.py"

The observer is deliberately read-only. It reads runtime status, selected files, "/proc", systemd properties, and the loopback MCP health endpoint.

It does not open the SQLite database, change configuration, or call nftables.

One important improvement is how it handles ambiguous records.

For example, two samples with exactly the same timestamp cannot reliably be ordered because the format does not contain a sequence ID.

Instead of silently choosing one, the observer rejects the ambiguous records:

if len(group) > 1:
# No sequence ID exists to establish which same-time snapshot
# is authoritative. Reject every record at this timestamp.
for _, file_path, line_number in group:
_record_input_issue(
issue_state,
file_path,
line_number,
f"duplicate timestamp {timestamp}; ordering is ambiguous",
)
continue

The summary also checks for:

Invalid JSON and unsupported schema versions.
Invalid or suspicious timestamps.
systemd inspection failures.
Service restarts and inactive states.
Memory and CPU measurements.
Mixed Agentix versions during one observation window.
Firewall shedding and ingress counter inconsistencies.
MCP health failures.
Sampling gaps.

The systemd timer runs every 15 minutes and writes observation records to:

"/var/lib/agentix/observe/"

A manual sample on a deployed host can be requested with:

sudo -u agentix \
/opt/agentix/.venv/bin/python \
/opt/agentix/tools/shadow_observe.py sample --stdout

After the observation window, the summary can be generated with:

sudo -u agentix \
/opt/agentix/.venv/bin/python \
/opt/agentix/tools/shadow_observe.py summarize \

shadow-summary.json

The runbook defines two evidence gates:

24 hours: an initial observation coverage gate.
7 days: a longer evidence coverage gate.

These gates require continuous-enough samples, enforcement to remain off, and anomalies to be investigated. A green-looking process status alone is not sufficient evidence.

Source: ""tools/shadow_observe.py"" (https://gitlab.com/jakubrojicek11/agentixlite/-/blob/68f6d33527a34cfde1dc85b7c1bdcdb2e51acff6/tools/shadow_observe.py)

3.3 MCP: unknown must remain unknown

The Go gateway now exposes an explicit "enforcement_enabled" status field.

The relevant Go type is:

type Status struct {
SchemaVersion int json:"schema_version"
AgentixVersion string json:"agentix_version"
EnforcementEnabled *bool json:"enforcement_enabled"
}

Notice the "*bool".

A normal boolean has two values: "true" and "false".

A pointer also allows the value to be absent. That gives the gateway a way to distinguish an explicit "false" from a status snapshot that does not contain the field at all.

This matters for compatibility with older runtime status files.

The MCP gateway remains a read-only interface. It exposes sanitized host telemetry, not raw request bodies, source code, secrets, or per-request payloads. Its tools cannot modify firewall state or Agentix configuration.

The Python core remains the authority for security decisions.

Source: ""go-gateway/main.go"" (https://gitlab.com/jakubrojicek11/agentixlite/-/blob/68f6d33527a34cfde1dc85b7c1bdcdb2e51acff6/go-gateway/main.go)

3.4 Architecture-aware binaries

The installer now selects the correct MCP gateway binary based on the Linux architecture.

The selection is explicit:

case "$arch" in
x86_64|amd64)
binary="agentix-mcp-linux-amd64"
;;
aarch64|arm64)
binary="agentix-mcp-linux-arm64"
;;
*)
echo "Unsupported Linux architecture: $arch" >&2
exit 2
;;
esac

The selected binary is copied to the architecture-neutral path:

"agentix-mcp"

This allows the systemd service to use one executable path without embedding an architecture-specific filename.

The build system now covers four binaries:

Component| Linux AMD64| Linux ARM64
Go MCP gateway| Yes| Yes
Native event validator| Yes| Yes

The GitLab reproducibility job uses Go 1.23.2 and rebuilds all four binaries from source.

It then compares each clean build with the committed binary using "cmp".

That is stronger than simply checking whether a binary starts. It checks whether the committed artifact is byte-for-byte identical to the output of the pinned build process.

The npm package remains Linux x64 only.

Source: ""Makefile"" (https://gitlab.com/jakubrojicek11/agentixlite/-/blob/68f6d33527a34cfde1dc85b7c1bdcdb2e51acff6/Makefile)

3.5 What was actually tested?

I wanted this release to have evidence behind it, not just a longer changelog.

Here is the validation record.

The Go build and validation work used the pinned Go 1.23.2 toolchain. The four committed binaries were rebuilt in an Ubuntu PRoot environment and compared with the source builds.

The two skipped npm tests on Android are important context: those integration checks require Linux x64. They were not counted as successful Android tests. The Linux CI package job ran separately and passed.

The merge-request pipeline was:

""Pipeline 3016577090"" (https://gitlab.com/jakubrojicek11/agentixlite/-/pipelines/3016577090)

After the merge, the "main" pipeline also completed successfully:

""Pipeline 3016604499"" (https://gitlab.com/jakubrojicek11/agentixlite/-/pipelines/3016604499)

3.6 What is not proven yet?

This part is just as important as the green tests.

There is no recorded real-VPS validation run for v0.8.2 yet.

The current evidence covers local regression tests, mocked nftables scenarios, Go tests, package validation, and reproducible builds.

It does not prove how Agentix behaves under real production traffic on a Debian or Ubuntu VPS.

The next validation step is deliberately conservative:

Use a dedicated Debian or Ubuntu VPS.
Keep "enforcement_enabled = false".
Install Agentix and verify that MCP remains bound to loopback.
Collect Shadow Mode samples.
Review the 24-hour and 7-day summaries.
Investigate restarts, dropped events, storage pressure, firewall shedding, and false-positive candidates manually.

Automatic enforcement should not be enabled simply because the services remain running.

A synthetic test is useful. A real host observation is a different kind of evidence.

Final thoughts

Agentix Lite Sentinel v0.8.2 is primarily a deployment-hardening and observability release.

The most important changes are not flashy features. They are the checks that prevent an installer from blindly changing unfamiliar firewall rules, the diagnostics that make incomplete observations visible, and the build pipeline that verifies architecture-specific binaries against their source.

The project still has a real-world validation step ahead of it.

That is intentional. I would rather publish a clear boundary between what passed and what remains untested than call a prototype production-ready too early.

Experiment first. Headline second.

Source and evidence