GlassHood is AI monitoring for integration pipelines and complex systems. Read-only collectors bring in the logs and measurements of every component, deterministic checks run first and AI on top, and one dashboard shows business and IT where the system and each component stand.
AI reads every component’s logs; one dashboard shows business and IT where the system and each component stand; alerts reach the right people by severity, with tickets and regular updates.
How it is actually built — host, identity, region, packaging — then the full topology and how every part connects.
Every read of the monitored cloud project uses a short-lived, viewer-only token, and only list, get and describe calls exist; a compromised engine still cannot write to it, and there is no stored cloud key to steal.
Claude, Cursor and other MCP clients can read the public demo — topology, impact analysis and node logs — through three read-only tools, with no login or key.
These are the concrete bindings of the architecture above — the cloud, region, identity mechanism and packaging. They are swappable implementation choices, not the architecture.
The whole flow, in order: a target system → read-only collectors (this section) → one topology graph (live discovery merged with the landscape file) → a deterministic + statistical tier that produces the metric signals → an AI layer on top that summarizes the state and reviews the logs → the dashboard, alerts, tickets and regular updates for business and IT, compliance evidence and a read-only API. The sections below walk it in that order.
GlassHood installs nothing in the system it watches. Background collectors poll on cadences and,
toward the monitored cloud project, every call is list / get /
describe — a search across the collector and discovery code finds zero
create / delete / update / patch /
insert calls toward the target. Read-only is enforced twice: by that call surface,
and by the identity itself — a short-lived, viewer-only federated token with no stored
keys (detail under Implementation). Even a full compromise of the engine cannot write to
the monitored cloud project.
In this use case — monitoring a solution on Google Cloud — the collectors read:
Every collector runs on one shared 10-minute interval, and so do the per-part checks from the landscape file; the AI overview and the AI log review run every 3 hours.
ColdVault’s own metrics. Every 10 minutes GlassHood also reads coldvault.ai/api/metrics with an identity token of its own, valid for at most one hour and only for that address. Its Azure identity is exchanged through Google’s workload identity federation, and that federated identity mints the token for a dedicated Google account with no roles. The token is reused while it is valid and renewed before it expires, and it is never logged or shown; GlassHood holds no key or password for ColdVault. The ColdVault VM part shows RAM, disk, uptime and version from it. When a read fails, the metrics bar says why and when, the old numbers are dropped instead of being shown as current, and the RAM and disk alarms show “not checked”.
The cross-cloud part is the host/target separation — the engine runs on one cloud and reads a system on another, with no stored keys. Pointing it at a different target’s stack means writing new collectors, not just changing config. The architectural decision is the model itself: pull-based, read-only by construction.
The metric signals are produced by a deterministic + statistical tier; an AI layer then summarizes the state and reviews the logs. The GxP payoff: every deterministic alert can be reproduced without the model, and every AI alarm quotes the log lines it rests on, so a person can check it.
The deterministic / statistical tier (reproducible, runs every build):
These run together to produce every rule alert and anomaly. The AI layer runs on top of them: a model on Vertex AI, in the monitored Google Cloud project, reached with GlassHood’s key-less identity; no model weights are in the engine. At start and then every 3 hours it writes a short overview of the whole system and of each part: a sentence or two on the state, what needs attention, the next steps and a suggested 1–10 read. For an overview it is given only each part’s status, check result and metrics, with recent warning and error lines and a small sample of the other log lines; anything that looks like a credential is removed first. Every 3 hours it also reviews the logs at the locations each part’s landscape entry names and raises its own alarms, a separate kind labelled as found by AI review. An AI alarm must quote log lines it was given, or it is dropped; a critical one stays until a signed-in person acknowledges it, and who and when are recorded; a warning ends by itself when the problem is no longer seen. A signed-in operator can ask it to investigate one alarm deeper: that investigation reads further back in the logs, may search the web for the error, and writes a report with an executive summary. A daily cap on model calls, sized for about $2 a day, bounds the spend. The read and the AI alarms are AI syntheses, not deterministic verdicts.
Engine vs instance: the AI prompts are generic. They are given the monitored system’s parts by their labels, with their statuses, metrics and log lines, so pointing the analysis at another target needs no new prompt; the deterministic tier is target-agnostic too.
Business owners and IT teams read the same dashboard. A live map shows every component and every connection with its health, refreshed every 10 minutes, and the AI overview says how the whole system and each component are doing and what needs attention. Each component’s logs are one click away: a log viewer shows the entries from the locations its landscape entry names. Viewer, operator and admin roles decide what each signed-in person may do, and nothing anyone does on the dashboard changes the monitored system.
Alerts to the right people. Every alert carries a severity: critical, warning or info. Rule alerts and anomalies come from the deterministic tier, AI alarms from the log review (above). Each severity has its own distribution lists: GlassHood sends each alert by e-mail to the lists set for its severity, with a link to the alert on the dashboard. A critical AI alarm stays until a signed-in person acknowledges it.
Tickets in your ticketing system. GlassHood connects to the customer’s ticketing system; for ServiceNow, through its Table API. It opens an incident for each new critical or warning alert, with the urgency and impact set from the alert’s severity, and it links alerts with the incidents and the earlier change tickets on the same component, so a component with repeated tickets stands out. The connection is set up for each deployment, with the customer’s ServiceNow address and account.
Regular updates, as agreed. On the schedule agreed with each customer, GlassHood sends an update to the agreed recipients: the system’s status, the open tickets and who is working on them, each with a link to the dashboard or the ticket.
The source of truth for topology is neither pure auto-discovery (which misses non-enumerable nodes and carries no intended state) nor a pure declarative manifest (which goes stale the moment it is written). GlassHood merges both: live discovery is overlaid with declarative YAML manifests into a single enriched graph, rebuilt with fresh metrics every cycle.
Because the model carries observed reality and declared intent in one place, the gap between what was designed and what is actually running is visible in the model rather than requiring a separate system, and change between cycles is tracked. Every analysis layer reads from this one graph.
That model, and the alerts, anomalies and analysis around it, live in in-memory caches with no database. A restart loses history by design — that keeps the observation core a pure read/compute path with no write surface of its own. The live ALCOA+ audit trails are bounded in-memory ring buffers (they drop oldest and reset on restart).
Durable retention is a deliberately separate, default-off write path (a hot/warm analytics store plus cold object storage, with GxP no-auto-delete) — and it is also where the enduring ALCOA+ evidence lands when a deployment needs it kept. Splitting “observe” (in-memory, read-only) from “retain” (optional, write) is a boundary decision with real blast-radius and data-retention consequences.
GlassHood grants nothing because of where a request comes from. The three zero-trust principles map onto its design:
Who is who:
AI assistants and agents can read GlassHood’s public demo through the Model Context Protocol (MCP), the open standard by which they use outside tools. The MCP server runs on the user’s own machine next to the assistant — Claude Desktop, Claude Code, Cursor and others — and calls GlassHood’s public demo endpoints over HTTPS. Its three tools only read:
get_topology — every node of the demo estate with its status, metrics and diagnostics, the edges between nodes, and the overall status.get_impact_analysis — GlassHood’s analysis of the estate: a health score, a summary, the open issues and the recommended actions.get_node_logs — the recent log entries of one node from the topology.No login, key or customer data is involved: the demo is a curated sample estate. Answers are GlassHood’s own data, passed through unchanged and never cached. When GlassHood is asleep, a tool says so and names app.glasshood.ai as the way to wake it, instead of returning old data as current.
How the usual MCP risks are handled:
GlassHood as an MCP client. GlassHood also uses MCP the other way round: it checks ColdVault (coldvault.ai) through ColdVault’s MCP server, anonymously and with no key. Every 10 minutes it calls verify_attestation with a fresh nonce of its own, and its “Confidential hardware” component is healthy only when the proof is verified and bound to that nonce; otherwise it shows ColdVault’s reason. A signed-in person can press “Recheck via MCP”, which sends one short question through ask in Vault Mode; regular checks never call ask, the answer is treated as untrusted and is not stored, and Live demo cannot trigger it.
Compliance is not a pre-baked attestation. Reports are generated on demand, derived from what the engine actually observed — rule alerts, CVE findings and anomalies — with a per-subsystem ALCOA+ audit trail. You cannot fake what the engine observed directly; the evidence is the observation.
Those reports are aligned to EU GMP Annex 11, ALCOA+ and 21 CFR Part 11 and support human review; they are unsigned and are not an independent validation or certification. A qualified person reviews and adopts every artifact.
The engine holds no Google Cloud service-account keys anywhere. At runtime the Azure Container App’s
Entra managed identity is surfaced via IDENTITY_ENDPOINT / IDENTITY_HEADER (the
Container Apps endpoint, not the VM IMDS). A small broker fetches that token and hands it to
google-auth’s executable credential source, which exchanges it at Google’s STS for a
federated token and impersonates a viewer-only service account — a short-lived,
read-only access token, refreshed on demand.
The federation config (placeholders only)
{
"type": "external_account",
"audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
"token_url": "https://sts.googleapis.com/v1/token",
"service_account_impersonation_url":
"https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_EMAIL:generateAccessToken",
"credential_source": { "executable": { "command": "/app/az-token.py", "timeout_millis": 5000 } }
}
Sanitized — every identifier is a placeholder. This is the trust binding, not a secret: there is no key to leak.