ACTIVE DEVELOPMENT / SECURITY ENGINEERING
Defined capabilities. Controlled operations.
I built a self-hosted Model Context Protocol server to help AI clients inspect and assist with Linux infrastructure. The engineering challenge is defining exactly which operations are available, validating their inputs, and keeping administrative changes within explicit boundaries.
This project connects my interests in entry-level cybersecurity, Linux administration, monitoring and AI tool security.
Architecture at a glance
A conceptual view of the system. Expand a component to explore its role.
01 / AI client
An MCP-compatible assistant requests a specific registered tool with structured arguments.
02 / MCP tool boundary
The connector exposes defined operations rather than a general-purpose shell. Requests are routed through their tool contracts.
03 / Permission and input checks
Administrative contracts specify a write scope and request identifier. Some operations also constrain target hosts, fields, profiles or condition builders; removal tools describe local administrator confirmation.
04 / Infrastructure integrations
Read-only tools expose host health, Docker container states, systemd services, storage and LibreNMS monitoring information.
Current capabilities and evidence
| Capability | Evidence level | What was checked |
|---|---|---|
| Server connectivity | Queried successfully | The MCP ping tool returned a successful response. |
| Host health | Queried successfully | The health tool returned memory, load and filesystem information. |
| Docker inventory | Queried successfully | The container tool returned a structured inventory and states. |
| Services, storage and network monitoring | Exposed tool contracts | Read-only interfaces are available; not exercised for this portfolio review. |
| Controlled administration | Exposed tool contracts | Network, group and alert operations declare write scopes, request identifiers and bounded parameters. No write action was executed. |
| Authentication, audit completeness and privilege isolation | Project design / further validation | The project documentation describes these controls. Their full enforcement requires source review and security testing. |
Try the authorization model
Simulated demonstration. No live server connection, infrastructure command or administrative request is made.
- Client identity
- Registered tool
- Permission check
- Input validation
- Decision
- Simulated audit event
Demo events will appear here.
Security decisions
Read-only first
Inspection tools let an assistant retrieve operational state without requesting a change. This portfolio review used only read-only tools.
Bounded administrative tools
Tool contracts limit supported fields and targets. Alert rules use enumerated conditions rather than raw SQL or arbitrary builders.
Human review for destructive changes
Removal tool descriptions require local administrator confirmation. The demo illustrates that gate without executing an operation.
No public infrastructure access
The portfolio is a static case study with local browser simulation. It contains no LF1 credentials, internal addresses, topology exports or live telemetry.
Threat model and validation plan
The main concerns are overbroad tool access, malicious arguments, replayed requests, leaked secrets and attempts by an agent to change its own authorization policy.
- Test permission boundaries with authorized and unauthorized identities.
- Exercise malformed inputs and targets outside approved lists.
- Verify request-identifier behavior and safe retry handling.
- Confirm audit coverage, redaction and protection against modification.
- Test approval gates in an isolated environment before production changes.
These are validation objectives, not a claim that a complete penetration test or security audit has been performed.
Development roadmap
| Area | Status |
|---|---|
| Working MCP connection and selected read-only queries | Verified in this review |
| Expanded read-only inventory and bounded administration | Interfaces exposed; validation ongoing |
| Authorization and audit enforcement review | Further source review and testing |
| Sanitized technical documentation and simulated demo | Available in this local portfolio preview |
| Independent backup monitoring and isolated demo environment | Proposed in project documentation; not verified here |
Engineering lessons
A useful AI integration starts with narrow tool contracts and a clear separation between current state and historical documentation. A successful read query demonstrates connectivity and functionality; it does not prove every security control is enforced.
The portfolio communicates the design and observed capabilities while keeping operational data private. A future public code or documentation link should point to a sanitized release, not a copy of production configuration.