Framework-Agnostic Architecture

High-Level Overview

Iron Book is designed to integrate with any agent framework or protocol. It builds upon the Agent Name Service (ANS) architecture – a DNS-like discovery and registry system for AI agents, compatible with Google's A2A and Anthropic's MCP protocols – so that agents can find and authenticate each other securely, regardless of underlying technology. Because many organizations use heterogeneous AI platforms (LangChain, LangGraph, custom agent systems), Iron Book’s architecture is protocol-agnostic and pluggable. This ensures seamless deployment across clouds, on-premises, or hybrid environments.

Technical Architecture

Agent Name Service (ANS)

ANS is a global directory where agents register their DIDs and capabilities. It uses DNS-inspired naming conventions (e.g. finance.acme.com.analysis.v1) to encode protocol, organization, and version. ANS entries include the agent’s public keys (PKI certificates) and metadata. Lookups are secure and capability-aware: an agent querying ANS will only receive contact info for agents authorized for its intended protocol or service level. As the whitepaper notes, “ANS provides a protocol-agnostic registry infrastructure that leverages PKI certificates for verifiable agent identity and trust”.

Protocol Adapter Layer

To remain agnostic, Iron Book includes adapters for different communication standards (A2A, Google’s MCP, custom RESTful or gRPC APIs, etc.). Adapters translate protocol-specific identity tokens into Iron Book’s internal representation. For example, an MCP (Model Context Protocol) message from an agent is intercepted and its DID-credential is validated before the request is forwarded.

Microservice-Based SaaS

Iron Book’s services (Identity, Policy, Logging, ANS) are exposed via REST/GraphQL APIs. Developers can deploy Iron Book as a cloud SaaS or on-premises microservices. A Kubernetes Helm chart is available for enterprise deployment, or it can run as managed SaaS with VPC integration. The architecture also supports serverless invocation (e.g. AWS Lambda) for event-driven extensions.

Inter-Framework Authentication

Because DIDs are ledger-based and not tied to any single vendor, Iron Book allows cross-framework trust. For example, a LangGraph agent and a custom Python agent can both register with ANS and verify each other’s credentials. The platform unifies identities so any analytics workflow involving multiple agent types is seamlessly secured.

Developer Integration (Example)

To discover or call another agent, developers use the Iron Book SDK to query ANS. For instance:

// Discover agents offering "sentiment-analysis" capability
results = IronBook.ANS.resolve(service="sentiment-analysis", org="AcmeCorp")
for entry in results:
    print(f"Found agent {entry.agentDID} at {entry.endpointUrl}")

// Call the agent using its DID-authenticated endpoint
sentiment = IronBook.Communication.send({
  "to": results[0].agentDID,
  "protocol": "MCP",
  "payload": { "text": "Analyze this text..." }
})

Under the hood, ANS.resolve performs a secure lookup (using the agent’s own DID for auth) and returns only those agents whose capabilities match. Iron Book enforces that each agent’s identity was verified via PKI as listed in ANS. This means developers do not need to configure static IPs or API keys; discovery and secure handshake are automated.

Compliance & Standards Mapping

A framework-agnostic approach aids standards compliance by ensuring uniform security controls across technologies:

Standard	Iron Book Compliance
ISO 42001	Demands interoperable controls for AI systems. By using open standards (DIDs, JSON Schema, REST APIs) and supporting multiple protocols, Iron Book aligns with ISO 42001’s requirement for flexible AI governance.
SOC 2/PCI DSS	These standards often require validated third-party components. Iron Book’s open registry (ANS) and adapter layer satisfy requirements for known, accredited services. The use of standard protocols (e.g. OAuth2, SAML, OpenID Connect) ensures that existing IAM certifications remain valid.
GLBA/HIPAA	Both regulations stress approved vendor management. Iron Book’s DI-centric model means that any agent (internal or third-party) must register and be vetted (credentials checked) before accessing data. This provides a clear attestation that only authorized services are in the ecosystem.
GDPR	Data processing across federated systems requires accountability. Iron Book’s namespace and registry ensure that every agent service (no matter what framework) is documented and controlled, simplifying GDPR’s requirement for data processing inventory.

IAM Interoperability

Iron Book’s platform integrates with enterprise IAM via standard protocols. For example, Azure Entra ID can federate with Iron Book by treating ANS as a custom claims provider: agents registered in ANS can have their DIDs mapped to Azure AD Enterprise Apps, enabling Azure Conditional Access to include agent attestations. Iron Book also supports OAuth2 flows for agent-to-resource access – any resource configured to trust an OAuth2 token from Iron Book (which in turn is backed by the agent’s DID) can grant access.

For AWS Cognito, agents can authenticate via Cognito Identity Pools using an OpenID Connect (OIDC) identity provider set to Iron Book’s token service. Essentially, Iron Book can act as an OIDC issuer for agents; tokens issued by Iron Book can be accepted by Azure or AWS IAM policies through OIDC federation.

This ensures agents behave as first-class citizens in existing IAM frameworks: e.g. Azure roles or AWS IAM roles can be granted based on Iron Book-issued token claims (such as the agent’s organization or role), bridging the decentralized identity with cloud identity providers.