AssureDomain

• 

  Evidence-bound plan, exact-hash approval, controlled name.com execution, and tamper-evident audit proof.

Inspiration

AI agents can launch services and modify infrastructure faster than teams can review every action. Domain registration is a dangerous boundary: availability changes, purchases are not casually reversible, premium inventory can be expensive, and an incorrect DNS write can silently route traffic to the wrong destination.

We built AssureDomain to give agents useful domain automation without letting a model guess its way through an irreversible operation.

What it does

AssureDomain turns versioned operational evidence into a governed domain and DNS workflow:

1. Accept promoted service-catalog and deployment facts.
2. Query live name.com Sandbox inventory and pricing.
3. Reject premium or unsupported acquisition paths.
4. Build an immutable SHA-256 plan containing the exact domain and DNS intent.
5. Require a human to approve that exact plan hash.
6. Re-check availability immediately before execution.
7. Register idempotently, create the approved DNS record, and read provider state back.
8. Issue a verified receipt and append every transition to a tamper-evident hash chain.

The important boundary is explicit: approval changes authorization, not truth. A changed plan needs a new decision.

How we built it

The application uses FastAPI and Pydantic for strict review and execution contracts, with a dependency-free responsive web console for the end-to-end workflow. A hexagonal provider port separates deterministic fixtures from the live name.com CORE v1 Sandbox adapter.

The name.com API is functionally central. AssureDomain uses:

• POST /core/v1/domains:search for live inventory and pricing.
• POST /core/v1/domains:checkAvailability immediately before execution.
• POST /core/v1/domains with an idempotency key for registration.
• POST /core/v1/domains/{domainName}/records for the approved DNS write.
• GET /core/v1/domains/{domainName}/records for read-before-write protection and final verification.

Security controls include two independent production-endpoint rejections, opt-in Sandbox writes, an execution key, an exact confirmation phrase, premium-domain fail-closed behavior, DNS replay protection, and no credentials in browser responses or logs.

Challenges we ran into

The hardest problem was not calling an API. It was defining where automation must stop. Search is safe to automate; registration and DNS require authoritative evidence, freshness checks, policy enforcement, human approval, idempotency, and provider read-back.

We also had to normalize apex DNS records because providers may represent the root host as either @ or an empty string. Treating those representations as different would create duplicate records or false verification failures.

Accomplishments that we're proud of

• A real name.com Sandbox registration and apex A-record creation is shown in the demo.
• The approved plan cannot be swapped or replayed after evidence changes.
• Five name.com operations form one required workflow rather than a decorative API call.
• The final receipt proves provider state and verifies a six-event audit chain.
• Ruff, Mypy strict, 19 tests, and Docker build all run in GitHub Actions.
• The container runs non-root with a read-only filesystem.

What we learned

Agentic infrastructure needs more than tool access. It needs semantic authority, immutable intent, explicit promotion and approval policies, idempotent external operations, and proof that the requested state actually exists after the write.

What's next

We plan to persist workflows in PostgreSQL, add organization identity and role-based approvals, consume service-catalog events, add signed provider webhooks, and expose the governed operation as an MCP tool that enterprise agents can safely call.

Live proof

The public demo shows a verified Sandbox workflow with domain registration order 2127577, one DNS record, six audit events, and a valid audit chain.

Built With

• core
• fastapi
• github
• name.com
• python