DEV Community: hassanismailtech

Ghost in the Machine: Building an Open-Source Privacy Boundary for AI Agents

hassanismailtech — Sat, 31 Oct 2026 22:52:30 +0000

AI agents are useful precisely where the stakes are high: customer support, financial operations, clinical workflows, and internal tooling.

That is also where they can accidentally send the wrong thing to an external model.

A bank-transfer agent may receive a customer’s name, phone number, account number, BVN, or NIN. A support agent may handle email addresses and sensitive tool results. Most AI integrations still treat the model request as the boundary: collect data, serialize it, send it upstream.

I wanted to invert that assumption.

Aegis is an open-source, inspectable data boundary for AI agents handling Nigerian identifiers. It sits between an application and an AI provider. Before a request leaves the application, Aegis’s Scrubber replaces detected sensitive values with session-stable Placeholders. The external Upstream sees only those Placeholders. When the response returns, the Reinjector restores known values for the calling application.

The goal is not to claim magic privacy or perfect detection. It is to reduce unnecessary data exposure while leaving evidence of what crossed the boundary.

This is the first public open-source release of Aegis under Apache-2.0.

The ghost I wanted to make visible

The “Ghost in the Machine” theme made me think about the data that silently follows an AI agent through a workflow.

An agent can look harmless on screen:

“Please initiate a transfer for this customer.”

But that sentence may carry identity data in the message body, an assistant tool-call argument, and later a tool result. If the agent sends all of it directly to a model provider, the sensitive information becomes invisible infrastructure: present in the request, absent from the product story, and difficult to inspect afterward.

Aegis makes that boundary visible.

Agent or application
        |
        v
     Aegis Proxy
        |
        +--> Scrubber --> Session Map
        |
        v
External Upstream receives Placeholders only
        |
        v
    Reinjector
        |
        v
Agent receives a usable response

The critical distinction is that Aegis is not an irreversible redaction tool. An agent may still need a name or account number to complete a local workflow. Instead, Aegis uses a short-lived Session Map to preserve a controlled association between an original value and its Placeholder for the current conversation.

For example, an external model can receive:

Initiate a transfer to [[PERSON_1]] using [[ACCOUNT_NO_1]].

The caller can still receive a coherent response after the Reinjector resolves known Placeholders. The external model never needs the original values to reason about the transfer flow.

Why Nigerian identifiers need first-class support

Generic PII tooling is useful, but production systems are contextual.

Aegis starts with a detector pack for Nigerian data patterns:

Phone numbers, including common +234, 234, and local forms
BVNs
NINs
Account numbers
Email addresses
PERSON entities, using a Nigerian name gazetteer and local GLiNER detection

The detector is deliberately layered:

Pattern rules identify structured values.
A gazetteer catches known Nigerian naming patterns.
A local GLiNER model finds PERSON entities the earlier layers miss.

Overlapping matches are merged, with the longest match winning. A repeated original value receives the same Placeholder within a Session, which matters when an agent sees a customer in one turn and uses a tool in the next.

The open-source AI component is central here, not decorative. GLiNER performs local entity detection inside the Scrubber before a request is sent to an external Upstream. Aegis uses open tooling to decide what must not leave the building in its original form.

The hard part: agents do more than chat

A text-only demo would have been easy to make look convincing. Real agents made the problem more interesting.

Aegis scrubs:

Message text
Assistant tool-call arguments
Tool-result content
OpenAI-compatible streaming responses
Anthropic Messages API content and tool inputs

That means the boundary follows data through the places where agents actually move it.

A normal client integration remains intentionally small:

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8000/v1",
    api_key="your-upstream-key",
)

The application points its client at Aegis. Aegis forwards a scrubbed request to the configured Upstream and returns a reinjected response where possible.

The same principle applies to streaming. Placeholders can be split across chunks, so Aegis uses a bounded hold-back buffer before reinjecting stream content. It does not assume that one network chunk contains one complete Placeholder.

What I chose not to promise

Privacy software earns trust by being explicit about its failure modes.

Aegis does not guarantee that every sensitive value will be detected. It does not make a data transfer lawful by itself. It does not claim “zero retention,” “zero knowledge,” or perfect recall.

Instead, it follows two conservative rules:

If the Scrubber or Session Map fails before an Upstream request, the request is blocked.
If reinjection cannot recover a Placeholder because the Session Map has expired or Redis has restarted, the response keeps the unresolved Placeholder rather than guessing a value.

That second choice can be inconvenient for an agent. It is also safer than manufacturing identity data.

The Session Map is intentionally ephemeral: Redis persistence and volumes are disabled in the supplied local stack, and its default sliding TTL is 300 seconds. That does not control an Upstream provider’s own retention policy; it simply prevents Aegis from turning temporary mapping state into a permanent database.

Making the boundary inspectable

A privacy boundary should be testable, not merely asserted.

Aegis provides a Wire Tap that records what the Upstream received after scrubbing. It never exposes pre-scrub request text or Session Map contents. Safe telemetry records counts, types, timings, IDs, and request status without recording sensitive bodies.

The included dashboard can show:

Detected-entity totals by type
Proxy overhead
Live safe telemetry
A selected Wire View of the post-scrub request sent Upstream

The demo uses synthetic data and a local mock Upstream. It is designed to make the contrast visible:

AGENT SAW:
  synthetic customer details

UPSTREAM SAW:
  [[PERSON_1]], [[BVN_1]], [[PHONE_1]], ...

That is the moment I wanted the project to create: the agent remains useful, but the “ghost” of raw identity data is no longer silently travelling across the network boundary.

Evidence, not a victory lap

I measured Aegis on a project-authored, held-out synthetic evaluation set of 220 sentences and 500 labelled entities.

Here are the results:

Measure	Result
Total recall	98.8%
Total precision	80.9%
PERSON recall	96.9%
PERSON precision	61.9%
Structured entity recall in this synthetic set	100%
Leak-test result	0 of 35 planted entities reached the mock Upstream

Those numbers need context.

The evaluation set is synthetic and project-authored, not an independent audit. PERSON precision is intentionally lower because Aegis prefers over-redaction to silently passing a likely sensitive name onward. The leak test uses the project’s own prompts, not adversarial third-party penetration testing.

Performance also depends on the path taken. On the development laptop, the pattern layer’s 60-word p50 was about 0.15–0.22 ms. Cold local model detection was much more expensive roughly 350–440 ms p50 on a 60-word prompt and long text can exceed the default two-second model timeout, which blocks the request rather than sending unscreened text Upstream. Cached and skipped model calls were far faster, around 0.4 ms p50.

That trade-off is the project’s real engineering tension: protect first, measure honestly, and fail closed when the protection layer cannot make a safe decision.

Why open innovation matters here

Aegis is open source because a privacy boundary should be inspectable by the people who depend on it.

Users should be able to examine:

What patterns are recognized
Which data reaches the Upstream
How Placeholders are created and restored
How failures behave
How measured recall and latency were produced
What the project does not claim

The system can run with a local mock Upstream for demonstration and testing, and its detection layer uses local open-source tooling. That makes it possible to inspect the actual boundary rather than accept a black-box promise about it.

For organisations handling Nigerian identifiers, open innovation is not only about being able to modify source code. It is about being able to ask a precise question:

“What exactly left our environment?”

Aegis is my attempt to make that answer concrete.

Run it locally

The repository includes a Docker Compose stack with Aegis, Redis, and a mock Upstream:

git clone https://github.com/hassanismailtech/Aegis.git
cd Aegis
cp .env.example .env
docker compose up --build

Then run the test suite:

uv run --directory backend pytest -q

For the held-out synthetic evaluation:

uv run --directory backend python scripts/eval_heldout.py --floor 0.85

And for the benchmark:

uv run --directory backend python scripts/bench_scrub.py

Please use synthetic data in local demos. Do not put real customer, banking, health, or identity data into a public test environment.

What comes next

Aegis is not finished, and that is part of why I am releasing it openly.

The next useful work is not to make broader privacy claims. It is to improve the evidence:

Independent evaluation data and review
More language and regional entity packs
Better calibration for PERSON over-redaction
Clear deployment guidance for in-country or customer-controlled environments
More adversarial leak testing

If you build agent systems that touch sensitive data, I would value the most specific feedback possible: what data shape would your agent accidentally send, and how would you want the boundary to behave?

Source code, tests, synthetic evaluation, and documentation are available in the Aegis repository.

References and acknowledgement

The wider community is actively exploring PII minimisation and privacy boundaries for AI systems. Two useful perspectives while building Aegis were:

saaro, “Presidio 2026: PII Detection and Anonymization for GDPR-Compliant AI Pipelines”
Teo Crispin, “Building an Information Firewall for AI Agents”

Aegis takes a different approach: Nigerian-aware detection, session-stable reversible Placeholders, coverage for tool calls and tool results, and a Wire Tap that makes the post-scrub Upstream boundary reviewable.

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth!

hassanismailtech — Sat, 31 Oct 2026 22:10:06 +0000

CampusSync turns a user-supplied campus notice into a reviewable calendar action while keeping evidence, uncertainty, and verification honest.

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth

At LASUCOM, an important academic update can arrive as a paragraph in a busy group chat, an image flyer, or a paper notice that someone photographs and forwards. That is normal. The problem is that a date buried in that flow is easy to miss—and turning it into a reliable calendar action is still manual work.

I built CampusSync at Hacktoberfest Hack Day Ikeja × Build54 & LASUCOM to make that one step easier:

A student supplies a campus notice. CampusSync turns it into a reviewable, calendar-ready action—without pretending that an AI model is the institution.

The project is open source under the MIT License: github.com/hassanismailtech/campusync.

It is also deployed with a real inference path. The primary route uses Gemma 4 inference hosted on DigitalOcean, funded with MLH credits, and it falls back to OpenRouter when the primary provider is unavailable. Both provider tokens live only in Vercel environment variables; the browser never receives them.

The problem was not “we need another feed”

The obvious first idea is a better announcement feed. I think that misses the actual pain.

Students are often already surrounded by notices. The failure happens between seeing a message and acting on it. An exam time, a dues deadline, a posting, or an association event may exist, but it lives in a format that is hard to search, filter, or put in a calendar.

The other failure is trust. A plain AI summary can sound more certain than the original notice. For a deadline or an assessment, that is the wrong trade-off. A useful system has to make it easy to check what it relied on—and clear that it has not magically verified the notice.

The design rule: the Mirror Principle

CampusSync follows one constraint that shaped every implementation choice:

CampusSync does not create news. It mirrors a user-supplied notice and preserves the evidence needed to review it.

Each action is designed to retain a source excerpt, an explicit unverified state, and enough context for a student to decide whether to add it to a calendar. “Locally verified” means the user checked it; it does not mean LASUCOM, a department, or an association officially verified it.

That sounds like copywriting, but it changes the architecture:

No WhatsApp scraping or automated group ingestion.
No claims that the product is an official LASUCOM channel or partner.
No server-side storage of raw notice content in this hackathon build.
No fallback that quietly invents an extraction when the model is unavailable.
Fictional/sample data is visibly labelled rather than presented as real notices.

What I built

The working local experience includes:

a Vite/JavaScript dashboard for notice capture, a feed, an exam tracker, and a searchable LASUCOM-focused directory;
text capture with input validation and client-side flyer preview;
browser-local drafts and local filtering;
Google Calendar links and RFC 5545 .ics export for Africa/Lagos; and
a serverless extraction route that is wired for Gemma-capable providers through server-only credentials.

The directory intentionally does not manufacture contact details: entries use “Contact information to be confirmed.” That is a small choice, but it reflects the larger one: a credible information tool should be comfortable saying “I do not know.”

flowchart LR
  A[User-supplied text or flyer] --> B[Validate and preview in browser]
  B --> C{Secure provider configured?}
  C -->|Yes| D[Server-side extraction request]
  C -->|No| E[Fail closed with a clear message]
  D --> F[Unverified local draft]
  F --> G[Evidence-aware review]
  G --> H[Google Calendar or .ics export]

A real AI path, with a failure mode I can explain

Messy flyers and informal campus language are not a rules-engine problem. CampusSync sends a user-supplied notice to a serverless Vercel route. The route calls DigitalOcean’s hosted Gemma 4 inference first; if that request fails, it tries an OpenRouter Gemma fallback. The response is constrained to a structured draft, not treated as a verified notice.

Browser
  → Vercel /api/extract
      → DigitalOcean Gemma 4 (primary)
      → OpenRouter Gemma (fallback)
  → unverified draft for human review

The keys are Vercel server-side environment variables. They are not VITE_ variables, not bundled into the client, and not committed to Git. The route also has a deliberate failure mode: if neither provider succeeds, it returns an error stating that the notice has not been analysed. It does not fabricate a result just to make a demo feel smooth.

That matters to me more than a flashy “AI worked” screen. Gemma is not a decorative chatbot in this project: it is the component that converts messy language into a usable draft. Its open-weight model family also keeps the architecture replaceable and creates a credible future path for an institution to host inference under its own controls. But the model is only one part of the product. The practical value comes from the workflow around it: capture, evidence, review, local filtering, and calendar output.

The access-control foundation is already there

CampusSync is currently useful without making every student create an account. When a person needs to contribute or manage content, Supabase provides the live authentication path: Google OAuth and email magic links are wired into the client.

The Supabase schema defines the building blocks for a responsible publishing workflow:

profiles for the user’s campus context;
organizations for departments, associations, and other publishers;
user_roles for admin, moderator, and org_rep roles;
announcements and exam_schedules as separate data models; and
Row Level Security policies that constrain who can read, create, update, or delete sensitive content.

An organization representative, for example, is not meant to have universal publishing power. The authorization helpers check the authenticated user’s role and organization before allowing changes. This is the foundation for a future where publishing is accountable instead of simply “anyone with a login can post.”

The important distinction is still the Mirror Principle: authentication controls who may publish, but it does not turn an unverified AI draft into an official institutional fact.

A technical detail I did not want to get wrong: time zones

Calendar bugs are quiet. A correctly extracted 9:00 AM exam can become a 10:00 AM appointment if an .ics file is incorrectly treated as UTC.

CampusSync emits local floating date-times and writes X-WR-TIMEZONE:Africa/Lagos into its calendar output. Deadline-only records become all-day events. The test suite also checks that the generated DTSTART is not silently suffixed with Z, which would shift the time.

const lines = [
  'BEGIN:VCALENDAR',
  'VERSION:2.0',
  'X-WR-TIMEZONE:Africa/Lagos',
];

This is not the most glamorous part of the build, but it is the kind of correctness users notice exactly when it fails.

How I tested the smallest claims I could make

I kept the checks aligned with what the repository actually promises:

text-length validation;
calendar generation for timed and deadline-only items;
Africa/Lagos calendar links;
the fail-closed behavior when provider configuration is absent;
six directory categories and 60+ directory entries; and
a guard against invented contact details.

That is not a clinical accuracy study. It is a testable baseline for a live, review-first workflow and a guard against silently degrading to invented output.

What I learned

I started with “can we extract dates from campus notices?” and ended with a more useful question: what should a system do when it might be wrong?

For a high-stakes notice, a confident answer is not enough. The user needs to see the source words, understand what is uncertain, and stay in control of the final calendar action. In other words, the trust layer is not decoration around an AI feature, it is the product decision.

From a campus tool to a customisable campus operating layer

The grand ambition is larger than a notice reader. CampusSync could become a customisable campus operating layer: an open-source core that each institution configures for its own faculties, organizations, academic calendar, verification practices, and channels.

Moodle is a useful inspiration here not because CampusSync wants to replace an LMS, but because an extensible open-source core can be adapted to radically different local institutions. CampusSync’s equivalent would be much narrower and more action-oriented: transform fragmented information into accountable, personalised next steps.

That future platform could support modules for:

verified notice publishing and source-memo evidence;
organization- and cohort-specific feeds;
revision history when a date, venue, or deadline changes;
calendar and reminder integrations;
opportunity tracking for scholarships, grants, and hackathons; and
approved connections to LMS or student-information systems.

The point is not to build all of that now. The point is to make today’s smallest useful workflow extensible without pretending it is already a campus-wide operating system.

What comes next

The next step is not to claim that CampusSync is an official campus system. It is to test a small, consent-based pilot with students and class representatives.

Before an institutional rollout, the project still needs a named owner, an approved publishing workflow, a privacy review, and clear operating responsibility. The technical foundation, live inference, authentication, roles, and RLS reduces the distance to that pilot; it does not replace institutional approval.

The metric I want to earn is simple: how many campus notices become real calendar actions each week?

Every campus runs on messages. CampusSync is an attempt to turn those messages into actions students can review and trust.

Try it

Source code: github.com/hassanismailtech/campusync
Local setup and project boundaries: README
License: MIT

Building My First Creao AI Agent: Notes from a Curious Med Student

hassanismailtech — Thu, 05 Mar 2026 02:37:16 +0000

I was intrigued when someone in a WhatsApp group said, "We're going to build AI agents this weekend. "My honest first reaction was: cool, I have always been curious to build this, so why not.

And it turned out to be very much more than I thought. Here's what I learned and why I think the AI agent era is more important than most people realise.

First, a Quick History Lesson (Bear With Me)

We've had "AI" in our pockets for years. Siri. Alexa. Google Assistant. They were impressive the first time you asked one what the weather was or to set a reminder. Then you realised they couldn't do much beyond that without breaking down.

Then came workflow automation, tools like Zapier, Make, and n8n. The idea was beautiful: if X happens, automatically do Y. No code needed. This genuinely multiplied productivity for a lot of people. But it was brittle. Change one thing in the pipeline and the whole thing collapses. Automation is obedient, not intelligent.

Then Large Language Models arrived, and everything shifted.

Not because they're smarter than humans (that debate can wait). But because for the first time, the gap between "having an idea" and "having a working thing" became tiny. You don't need to know how to code an API call. You describe what you want, and the model figures out the execution.

That's the setup. Now here's where it got real for me.

The Agent I Built (And What It Actually Does)

During the community training session run by a trainer on Creao AI, the lesson was to build a Telegram bot that automatically finds news and sends it to a chat, no manual searching, no copying and pasting, no formatting.

I followed the steps:

Created a Telegram bot via BotFather, got my API token
Got my Chat ID from a user ID bot
Pasted a structured prompt into Creao.AI with my token, chat ID, and topic filled in
Ran it

It worked. The agent searched Google News, pulled two fresh stories, summarised them in plain English, formatted everything neatly, and posted directly to my Telegram on its own.

But here's what I actually did with that knowledge:

I adapted it into the Webibyte ByteTips Bot.

Instead of generic news, my bot finds fresh bite-sized tech tips relevant to my startup's audience, developers, digital marketers, and small business owners in Nigeria and delivers them to a Telegram channel automatically. It's branded. It's useful. It runs while I'm doing personal studies.

That's the part that still gets me. A workflow that would have taken me 2–3 hours of manual research, writing, and posting runs itself.

I Also Automated Gmail to WhatsApp

The trainer also walked us through connecting Gmail responses to WhatsApp. I ran that one as-is, without modification, and it worked exactly as described.

Two agents. Two evenings. No code written.

I want to be careful not to oversell this. I didn't build something from scratch. I followed a structured tutorial, filled in my credentials, and understood what each part was doing. But that's also kind of the point, the barrier is now low enough that understanding the concept IS enough to build something real.

So What Is an AI Agent, Actually?

Here's the simplest, honest answer I can give:

A standard AI interaction is a transaction. You ask → it answers. Done.

An AI agent is a loop. You give it a goal → it plans → it uses tools → it acts → it evaluates → it adjusts. Over and over, without you approving each step.

The components:

A reasoning core (the LLM doing the thinking)
Tools (APIs, browsers, databases, etc., whatever the agent can call)
Memory (short-term for the current task, long-term for persistent context)
Action execution (actually doing the thing in the world)
Feedback (evaluating what happened and adapting)

What makes this different from automation is the reasoning layer. An automation fails when it hits something unexpected. An agent tries to work around it.

Why This Matters More

In Nigeria, for instance, the physician-to-patient ratio is critical. Administrative burden on medical staff is enormous. A lot of knowledge work that could be automated is still done manually, not because people don't know better, but because the tools either didn't exist or required expertise that most people don't have.

AI agents can change that math.

As a medical student and web developer. I don't have the hours to manually curate and post content, monitor industry news, AND still do my personal study. Agents give me leverage I couldn't otherwise afford.

And crucially, I believe the most powerful agents will not be built by the best engineers. They'll be built by people who most deeply understand the problem they're solving. A cardiologist building a clinical triage agent will out-build a generalist developer every time. My understanding of health communication in Nigeria is an asset in this space, not an afterthought.

That's democratising in a way that feels real, not theoretical.

What I'm Watching Next

A few developments I'm genuinely tracking:

Multi-agent systems: where specialised agents hand off tasks to each other. One agent researches, another writes, and another reviews. This is where things get interesting for complex knowledge work.

Persistent memory: agents that remember context across sessions, accumulating knowledge about you, your preferences, and your ongoing projects. Right now, most agents are stateless. That's changing fast.

Agents in African healthcare: structuring patient data, flagging anomalies, generating referrals, monitoring disease signals. The clinical and public health applications here are enormous and largely unbuilt.

One Honest Caveat

Security matters more than people admit in beginner agent tutorials.

Your bot token is a credential. Your Chat ID is sensitive. Any agent that authenticates with a third-party service needs those credentials to be kept private.

This isn't advanced knowledge. It's foundational. Treat it that way from day one.

TL;DR

AI agents aren't just smarter chatbots, they plan, act, and iterate toward a goal
I built two as a learner: a custom Webibyte ByteTips Bot for Telegram and an automated Gmail-to-WhatsApp pipeline
The real barrier now is understanding the problem you want to solve, not understanding the code
Domain expertise, clinical, cultural, and contextual is the actual competitive edge in the agentic era
For builders in Africa, this isn't just exciting. It's strategic.

I'm Hassan Ismail, a medical student, web developer, WEBIBYTE founder, and someone working at the intersection of health and technology in Africa. Find me at @hassanismailtech or drop a comment below.

[Boost]

hassanismailtech — Mon, 16 Feb 2026 08:56:54 +0000

BioSecure CLI: Building a Medical Command Center in 32 Minutes with GitHub Copilot Agents

hassanismailtech ・ Feb 16

#devchallenge #githubchallenge #cli #githubcopilot

BioSecure CLI: Building a Medical Command Center in 32 Minutes with GitHub Copilot Agents

hassanismailtech — Mon, 16 Feb 2026 07:16:36 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built BioSecure CLI, a terminal-based "Medical Command Center" designed to solve three critical failures in the Nigerian primary healthcare supply chain:

Messy Patient Data: A validator that automatically cleans and formats Nigerian phone numbers (e.g., converting 080... to +234...) using Regex.
Slow Triage: A clinical decision support tool that calculates BMI and flags Hypertensive Crises based on vitals.
Drug Stockouts: A logistics engine that tracks vaccine inventory and triggers "Critical Low" alerts to prevent expiry and shortages.

This isn't just a script; it's a prototype for a Closed-Loop Health Ecosystem intended to reduce drug "leakage" and improve patient outcomes in rural Nigeria.

Demo

Here is the entire development lifecycle, from empty folder to production-ready MVP, captured in real-time.

1. The Planning Phase (The "Architect")

I didn't start by writing code. I started by telling the Agent my vision. I asked for a 3-module system for Triage, Validation, and Logistics.

2. The Execution (The "Builder")

The CLI Agent autonomously created the project structure, set up the Python virtual environment, and installed dependencies (rich, pytest). I didn't type a single mkdir command.
"/>

3. The Logic Generation

I tasked the agent with complex logic, such as a "Phone Number Validator" for Nigerian formats. It wrote the code and the tests simultaneously.

4. The Result (32 Minutes Later)

In exactly 32 minutes and 47 seconds, the Agent delivered a fully tested, documented, and operational CLI tool.

Link to Source Code on GitHub

My Experience with GitHub Copilot CLI

As a medical student, I usually find terminal environments intimidating. My experience with the new Agentic Copilot CLI was transformative because it shifted my role from "Coder" to "Director."

Autonomy: I didn't have to look up syntax for the rich library or pytest. The agent knew what to install and how to use it.
Test-Driven Development (TDD): The agent automatically wrote tests for every module (Triage, Logistics, Validator) before I even asked. This ensured my medical logic was safe for patient use.
Documentation: It auto-generated a README.md and QUICKSTART.md at the end, saving me hours of writing.

This tool didn't just help me write code; it helped me build a product before my morning lectures even started.

Next Steps

This MVP is the foundation for a larger "BioSecure" ecosystem, including:

Phase 6: Database persistence (SQLite), which the Agent already planned for me.
Hardware Integration: Connecting the Logistics module to IoT Smart Shelves for real-time vaccine tracking.

DEV Community: hassanismailtech

Ghost in the Machine: Building an Open-Source Privacy Boundary for AI Agents

The ghost I wanted to make visible

Why Nigerian identifiers need first-class support

The hard part: agents do more than chat

What I chose not to promise

Making the boundary inspectable

Evidence, not a victory lap

Why open innovation matters here

Run it locally

What comes next

References and acknowledgement

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth!

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth

The problem was not “we need another feed”

The design rule: the Mirror Principle

What I built

A real AI path, with a failure mode I can explain

The access-control foundation is already there

A technical detail I did not want to get wrong: time zones

How I tested the smallest claims I could make

What I learned

From a campus tool to a customisable campus operating layer

What comes next

Try it

Further reading

Building My First Creao AI Agent: Notes from a Curious Med Student

First, a Quick History Lesson (Bear With Me)

The Agent I Built (And What It Actually Does)

I Also Automated Gmail to WhatsApp

So What Is an AI Agent, Actually?

Why This Matters More

What I'm Watching Next

One Honest Caveat

TL;DR

[Boost]

BioSecure CLI: Building a Medical Command Center in 32 Minutes with GitHub Copilot Agents

hassanismailtech ・ Feb 16

BioSecure CLI: Building a Medical Command Center in 32 Minutes with GitHub Copilot Agents

What I Built

Demo

1. The Planning Phase (The "Architect")

2. The Execution (The "Builder")

3. The Logic Generation

4. The Result (32 Minutes Later)

My Experience with GitHub Copilot CLI

Next Steps