Security Lessons From Making My Personal Hub Agent-Readable

The first rule of agent-readable systems:

Do not give the agent more power than it needs.

That rule shaped how I think about the API and MCP server behind my personal hub.

The goal is not to make the site "AI-powered."

The goal is to make public site context easier for software and agents to read safely.

Those are different things.

Public data vs private data

The first security decision is deciding what belongs in the public surface.

On my personal hub, public data includes:

• profile information
• public projects
• public products
• published notes
• public links
• public status fields
• public screenshots

Private data does not belong there:

• draft notes
• admin records
• analytics details
• billing data
• secrets
• private customer data
• internal dashboard state
• unpublished product plans

This sounds obvious, but agent-readable systems make the boundary more important.

When a tool exists, people and agents will try to use it.

The safest tool is one that cannot access private data in the first place.

Read-only first

For a personal hub MCP server, read-only tools are enough.

The useful questions are retrieval questions:

• Who is Orlando?
• What has he built?
• What products has he shipped?
• What notes has he written?
• Which projects use a specific technology?

None of those require write access.

That is why the MCP tools should retrieve public context, not mutate state.

No destructive tools.

No admin actions.

No "update profile" or "delete note" tool.

No "send email" tool unless there is a very clear permission model.

Read-only keeps the risk surface small.

Validate every input

Agent tools still need input validation.

Especially agent tools.

Models can pass:

• invalid slugs
• unexpected enum values
• overly broad queries
• malformed strings
• confusing locale values

Validation should happen at the boundary.

For example:

• slugs should match known content
• statuses should be finite enums
• locale should fall back safely
• limits should have maximum values
• unknown filters should not change behavior silently

Do not trust the model to always send clean arguments.

Treat it like any other client.

Rate limits still matter

Public read endpoints should have rate limits.

That is true even for a small personal site.

AI agents, crawlers, scripts, and experiments can generate more requests than expected. Rate limits make the public surface more predictable.

The goal is not to punish users.

The goal is to make the rules visible:

• how many requests are allowed
• when the window resets
• when a client should retry

Rate-limit headers are part of the developer experience.

They are also part of the safety model.

CORS should match the endpoint

CORS is not a complete security system, but it still matters.

For public read endpoints, permissive CORS can be reasonable because the content is already public.

For admin or private endpoints, CORS should be much stricter.

The mistake is treating every route the same.

Public content endpoints and private operational endpoints have different risk profiles.

They should not share the same assumptions.

Avoid draft leaks

Draft leaks are one of the easiest mistakes to make in content-driven systems.

If your content directory includes both published and unpublished work, the API and MCP layer need to respect that boundary.

A website page might hide drafts.

But an API endpoint might accidentally list everything if it reads the directory directly.

The rule:

If it is not meant to be public, it should be filtered before it reaches any public interface.

That includes:

• API responses
• MCP tool results
• search indexes
• RSS feeds
• sitemap generation
• structured data

One content source can power many outputs, so the publish boundary has to be explicit.

Do not leak secrets through summaries

Agent-readable systems often add summaries.

I like that pattern. My API responses include ai_summary fields because they help agents understand what came back.

But summaries need the same data boundary as raw responses.

Do not generate summaries from data the user should not see.

Do not include private metadata in "helpful" text.

Do not summarize internal state into a public field.

A summary is still output.

Treat it like output.

Tool descriptions should set expectations

MCP tool descriptions are also part of the safety surface.

They should not imply access the tool does not have.

Bad:

Gets all information about Orlando.

Better:

Returns public profile information for Orlando Ascanio. Does not include private contact records, analytics, drafts, or admin data.

That boundary helps the model answer honestly.

It also helps users understand what the tool can and cannot do.

Minimize tool power

The more a tool can do, the harder it is to reason about.

For a personal hub, narrow tools are safer:

get_projects
get_project
get_products
get_product
get_notes
get_note
get_orlando_bio

Each tool retrieves a specific kind of public content.

That is easier to validate, document, test, and monitor than one broad tool with vague behavior.

Security and clarity often improve together.

What I would avoid

For this kind of system, I would avoid:

• write-capable MCP tools
• tools that trigger external side effects
• exposing admin dashboards through MCP
• returning raw environment variables
• indexing unpublished drafts
• accepting arbitrary file paths
• accepting arbitrary URLs to fetch
• tool names that imply unlimited access

Most of these are not needed for a personal hub.

So they should not exist.

The core lesson

Making a personal hub agent-readable does not mean making everything agent-accessible.

It means exposing the right public context through stable, constrained interfaces.

The safest version is also the clearest:

Public content in.
Structured public context out.
No private state.
No destructive tools.
No unnecessary permissions.

That is enough to make the website useful to AI agents without turning it into an open control panel.

Future-proof does not mean reckless.

It means readable, structured, and bounded.