Agent Guardrails and Runtime LDAP Config
I worked on two different problems today. Both had the same goal: making boundaries explicit and easy to control.
The first task involved building MCP tools for an AI agent. I wanted the agent to manage an events platform by listing events, checking readiness, and publishing updates.
The challenge is that MCP tools use token authentication. This means they lack the session context a standard web request has. If you rely on a global tenant scope, the system might return data from every organization.
I solved this with three rules:
- Filter by organization explicitly in every query. Do not rely on a global scope.
- Use the same permission strings as the web app. An agent should never have more power than the human using it.
- Use UUIDs for lookups instead of auto-increment IDs.
Treat every tool as an untrusted endpoint. Put your logic where you can test it in one place.
The second task involved an identity portal. I moved LDAP settings from static files into a settings UI. Admins can now change host, port, and credentials without a new deployment.
I also added control over connection timeouts and SASL options. This created a technical hurdle with JSON.
When you store integer keys in JSON, they return as strings when you decode them. LDAP functions require integer keys. I had to write a mapper to convert those keys back to integers before use.
To keep this safe, I added two guardrails:
- Encrypt bind passwords at rest. Never put secrets in the cache as plaintext.
- Validate JSON fields before saving. A bad configuration should fail at the save step, not when a user gets locked out.
I also used a single assembler for both testing and saving connections. This ensures the connection you test is exactly what you save.
Engineering is not about building the feature. Engineering is about building the guardrails.
Source: https://dev.to/nasrulhazim/dev-log-2026-06-24-agent-guardrails-and-runtime-ldap-config-2hi5