# ASCENDING — Jarvis AI: Full Product Reference & FAQ > ASCENDING Inc. is an enterprise AI and cloud consulting company headquartered in Fairfax, Virginia. Its flagship product is Jarvis AI — a platform for governed enterprise AI adoption, available on the AWS Marketplace and Azure Marketplace. This document is the complete reference for the Jarvis AI platform: deep product descriptions plus an extensive, source-grounded FAQ. For the concise site index, see https://ascendingdc.com/llms.txt Jarvis AI is built around three principles: **security, control, and future-proofing**. It is licensed, customer-hosted software — not SaaS — that deploys directly into your own environment, so your data never leaves your infrastructure and never flows into any external system. Every AI interaction is governed through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress, with full audit logs of every interaction and agent action. Jarvis is built on open standards (the MCP and A2A protocols) so your stack evolves with the AI ecosystem without rip-and-replace. It runs anywhere you operate Kubernetes — AWS (EKS), Microsoft Azure (AKS), Google Cloud (GKE), plus hybrid and on-premises — and is procured through the AWS Marketplace and Azure Marketplace. The platform's two core products, **Jarvis Chat** and **Jarvis Registry**, are fully independent. Each works standalone; together they form a complete enterprise AI platform. ## Jarvis AI Platform Jarvis AI is ASCENDING's enterprise platform for governed AI adoption, balancing cost-efficiency, robust control, and future-proof flexibility. Because it is customer-hosted rather than SaaS, enterprises retain full data sovereignty: ownership of their data, AI interactions, and audit logs, with no shared infrastructure and no external data plane. Governance is enforced at the platform level — not left to individual users — through native Azure EntraID authentication, RBAC, granular per-user/per-team ACL policies, and OAuth-controlled egress. - **Deployment**: Any Kubernetes environment — AWS EKS, Azure AKS, Google Cloud GKE, plus hybrid and on-premises clusters. - **Procurement**: AWS Marketplace and Azure Marketplace. - **Standards**: MCP (Model Context Protocol) and A2A (agent-to-agent) protocols. - **Page**: https://ascendingdc.com/jarvis-ai/ ## Jarvis Chat Jarvis Chat is an enterprise chat interface that gives your team governed access to multiple AI models through one secure workspace — built for organizations that need control over who can use AI, what data it can access, and how it behaves, without sacrificing usability. - **Multi-LLM**: Integrates with OpenAI, Anthropic, AWS Bedrock, and more. Switch between models, compare outputs, and route requests to the right provider from a single interface; add new models without changing your setup. - **Access control**: SSO, RBAC, and SAML/OAuth via your existing identity provider — precise control over which users and groups can access specific models, tools, and knowledge bases. - **Data protection**: Built-in guardrails including PII detection, DLP (Data Loss Prevention) rules, and custom privacy policies so sensitive information is never exposed to AI models or external systems. - **Enterprise knowledgebase**: Upload documents and connect internal data sources for accurate, AI-generated answers grounded in your own organizational data (RAG) rather than generic internet content. - **Agents & automation**: AI-driven agents that automate routine tasks and orchestrate multi-step workflows end-to-end. - **Embed anywhere**: JavaScript SDK, Web Components, and iFrame support to embed a governed AI experience into existing portals, internal tools, or custom applications. - **Standalone or paired**: Works on its own (connect your own MCP servers, RAG pipelines, or integrations) and optionally pairs with Jarvis Registry. - **Page**: https://ascendingdc.com/jarvis-ai/jarvis-chat/ ## Jarvis Registry — Enterprise MCP & Agent Gateway Jarvis Registry connects any MCP-compatible AI copilot to your enterprise tools through a single, governed entry point. It handles centralized discovery, routing, authentication, and governance for all MCP servers and AI agents — giving your organization full control over what AI can access and how. It is fully independent of Jarvis Chat. - **Supported copilots**: Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, Jarvis Chat, and ChatGPT — any MCP-compatible client. One registry, every client; no duplicate per-tool or per-team configuration. - **Connected enterprise tools**: Jira, Confluence, Slack, Google Drive, Gmail, PostgreSQL, Snowflake, GitHub, Docker, and AWS. All copilot-to-tool traffic flows through one governed layer with consistent access controls and audit trails. - **Auto-discovery**: Intelligent discovery dynamically identifies available tools, resources, and skills based on context and permissions — copilots find the right tools automatically. - **Governance**: Fine-grained RBAC and ACL enforced at the tool level on every invocation; integrates with your IdP through OAuth and SAML. Governed at every tool call, not just at login. - **Encryption**: TLS for data in transit; credentials, tokens, and secrets encrypted at rest and decrypted only within your environment. - **Observability**: Real-time monitoring, analytics, anomaly detection, and complete audit trails (SIEM-integrable). - **Page**: https://ascendingdc.com/jarvis-ai/jarvis-registry/ ### MCP Gateway The MCP Gateway is the control and enforcement layer between AI clients and MCP servers. It centralizes discovery, authentication, policy checks, routing, and auditing for every MCP tool call — instead of configuring each copilot directly against each MCP server, you expose one governed endpoint and enforce consistent policy for all clients. - **Multi-cloud MCP federation**: Imports existing MCP servers from AWS AgentCore and Azure AI Foundry into one governed namespace without redeployment; servers keep running in their source environment while Jarvis applies unified RBAC, ACL, and audit policy. Cloud origin is transparent to clients. - **Auth elicitation**: Supports auth elicitation flows so MCP clients can be prompted to complete authentication when a downstream server requires user consent or refreshed credentials — secure per-user authorization without exposing raw credentials. - **Standards-based OAuth**: Validates OAuth 2.1 resource indicators (RFC 8707) for token scope binding (a token for one server cannot be replayed against another); enforces PKCE and per-user token lifecycle controls for inbound and outbound flows. - **Observability**: Trace and audit telemetry (identity context, policy decision, target server, result status), OTLP-compatible — forward to Datadog, Grafana, and other backends. - **Page**: https://ascendingdc.com/jarvis-ai/mcp-gateway/ ### Agent Gateway The Agent Gateway is the runtime endpoint through which AI copilots and applications invoke registered agents. Rather than each copilot connecting directly to each agent, all traffic flows through the gateway — which enforces authentication, applies RBAC and ACL policies, routes to the correct backend, and records the event for observability. - **Federation**: AWS AgentCore (via cross-account IAM role assumption) and Azure AI Foundry (via tenant credentials) — no agent-side code changes; existing agents keep running where they are. - **Orchestration**: Two models — a manual drag-and-drop pipeline (deterministic, auditable, for compliance-sensitive processes) and LLM-driven orchestration over a curated, permitted agent pool. The two can be mixed, including human approval gates. - **Agent security scan**: Every agent passes an automated scan (prompt injection patterns, capability misuse, policy compliance) as a publish gate before it can be invoked; re-scan triggers on any update. - **Observability**: An integrated OpenTelemetry collector instruments every layer without agent code changes — distributed traces, invocation metrics (latency, error rate, token usage, throughput), workflow events, and access decisions — exported via OTLP to Datadog, Grafana, Honeycomb, AWS CloudWatch, Azure Monitor, Jaeger, or Prometheus. - **Page**: https://ascendingdc.com/jarvis-ai/agent-gateway/ ### Agent Registry The Agent Registry is the authoritative catalog (the catalog plane) for every AI agent and MCP server in your enterprise — each registered with its identity, owner team, capability schema, access policy, and version before it can be invoked. The Agent Gateway (the data plane) reads from it and enforces policy at the moment of every invocation, using a local policy cache that is invalidated immediately on any registry update, so the registry never adds latency to invocations. - **Registration security**: Three checks before an agent goes active — capability declaration scan, prompt injection scan, and policy compliance check. Agents stay inactive until all pass; any card update re-triggers the pipeline. - **Real-time policy propagation**: Revocations and version deprecations reach the gateway immediately on the next invocation — a security requirement, not a cache TTL. - **Lifecycle**: Full version history, instant rollback by promoting a previous version, and per-team version-pinning for gradual rollouts — all recorded in the audit trail. - **Identity**: Any OIDC-compliant IdP (tested: Azure EntraID, Okta, Auth0, AWS IAM Identity Center); machine-to-machine via OAuth 2.0 client credentials with audience-separated JWTs. - **Autonomous & A2A**: Bounded agent pools make LLM-driven workflows safe; agent-to-agent invocations are first-class with full per-hop audit trails. - **Page**: https://ascendingdc.com/jarvis-ai/agent-registry/ ## Jarvis Capabilities ### Agent Flow (Jarvis AgentFlow) Task-driven AI agents for secure, governed automation. Agents orchestrate multi-step workflows (via Jarvis Registry), integrate with enterprise tools, and deliver governed AI at scale. Page: https://ascendingdc.com/jarvis-ai/agent-flow/ ### Governed AI Layer Adopt OpenAI, Anthropic, and AWS Bedrock with enterprise-grade governance built in: access control (SSO, RBAC, SAML/OAuth), guardrails, observability, LLM routing, compliance enforcement, and complete audit logs. Page: https://ascendingdc.com/jarvis-ai/governed-ai/ ### AWS AgentCore Federation Jarvis Agent Gateway federates AWS AgentCore and Azure AI Foundry agents into one governed experience layer. Existing agents keep running in their source environment while Jarvis applies multi-cloud RBAC, audit trails, and copilot access without redeployment. Page: https://ascendingdc.com/jarvis-ai/agent-gateway/agentcore-aifoundry-federation/ ### Claude on Amazon Bedrock Governance ASCENDING helps enterprises control Claude cost and pricing with Amazon Bedrock governance. The service includes cost attribution, real-time spending alerts, budget monitoring, team-level reporting, consolidated AWS billing, and a complete audit trail. Page: https://ascendingdc.com/jarvis-ai/claude-on-amazon-bedrock-governance/ ### AI Guardrails Proactive controls for safe, ethical, compliant AI: PII redaction, content filtering, topic filtering, RBAC, real-time alerts, and 100+ prebuilt compliance policies, plus DLP rules and custom privacy policies. Page: https://ascendingdc.com/jarvis-ai/guardrails/ ### Custom LLM Development ASCENDING helps teams adapt smaller open-source models to a defined business task using company data. Engagements cover fine-tuning and distillation, private cloud or on-premises deployment, MLOps workflows, and integration with tools, retrieval, and a governed knowledge base. Model selection, evaluation criteria, deployment boundaries, and handoff deliverables are agreed as part of the scope. - **Page**: https://ascendingdc.com/jarvis-ai/custom-llm-development/ ### RAG Knowledge Base Retrieval-augmented generation over your company documents with document citations, vector search, embedded PII guardrails, and AI agent integration — grounded in your own data, not generic internet content. Page: https://ascendingdc.com/jarvis-ai/knowledge-base/ ### Ambient AI for Healthcare HIPAA-compliant ambient intelligence for clinical care — capturing and documenting patient encounters, built on Jarvis's deploy-in-your-own-environment, governed approach. Page: https://ascendingdc.com/jarvis-ai/healthcare/ambient-ai/ ## Frequently Asked Questions ### Jarvis AI Platform **Do Jarvis Chat and Jarvis Registry have to be used together?** No — they are two fully independent products. Jarvis Registry integrates with any MCP-compatible copilot or AI client, including Microsoft Copilot, GitHub Copilot, ChatGPT, Claude Desktop, VS Code, and Cursor. Jarvis Chat works standalone and can connect to your own MCP servers, RAG pipelines, or knowledge bases. When used together, they form a complete enterprise AI platform, but neither product requires the other. **What makes Jarvis AI unique?** Jarvis AI is built around security, control, and future-proofing. It deploys directly into your environment, meaning your data never leaves your infrastructure or flows into any external system. Every AI interaction is governed through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress. It is also built on open standards like MCP and A2A protocols, so your infrastructure evolves as the AI ecosystem does without ripping and replacing. **Is Jarvis AI a SaaS product?** No. Jarvis AI is licensed, customer-hosted software. We intentionally avoided the SaaS model because enterprise customers require strict data sovereignty and compliance. You maintain full ownership of your data, AI interactions, and audit logs, with no shared infrastructure and no external data transmission. **What does governed AI adoption mean with Jarvis AI?** Governed AI adoption with Jarvis AI means every AI interaction is controlled at the platform level rather than left to individual users. It is enforced through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress, with full audit logs of every AI interaction and agent action. This gives an organization control over who can use AI, what data it can access, and how it behaves. **What is AWS AgentCore federation in Jarvis Agent Gateway?** AWS AgentCore federation in Jarvis Agent Gateway lets organizations bring AWS AgentCore and Azure AI Foundry agents into one governed experience layer. Existing agents keep running in their source environment while Jarvis applies multi-cloud RBAC, audit trails, and copilot access without redeployment. **How does Jarvis Agent Gateway federate AWS AgentCore and Azure AI Foundry agents without redeployment?** Jarvis Agent Gateway federates AWS AgentCore and Azure AI Foundry agents into one governed experience layer while leaving the agents in place. The gateway applies Jarvis governance controls, including RBAC, audit trails, and governed copilot access, so teams do not need to redeploy the agents themselves. **What is Claude on Amazon Bedrock governance in Jarvis AI?** Claude on Amazon Bedrock governance is a Jarvis AI service that helps enterprises control Claude cost and pricing. It includes cost attribution, real-time spending alerts, budget monitoring, team-level reporting, consolidated AWS billing, and a complete audit trail. **How does Jarvis AI help control Claude cost on Amazon Bedrock?** Jarvis AI helps control Claude cost on Amazon Bedrock through department-level cost attribution, real-time spending alerts, budget monitoring, team-level reporting, consolidated AWS billing, and a complete audit trail. The goal is to make Claude spend visible and governable inside the enterprise's AWS environment. **Why did ASCENDING build Jarvis AI as customer-hosted software instead of SaaS?** ASCENDING intentionally avoided the SaaS model because enterprise customers require strict data sovereignty and compliance. Jarvis AI is licensed, customer-hosted software that deploys directly into your environment, so you maintain full ownership of your data, AI interactions, and audit logs. There is no shared infrastructure and no external data transmission. **Does Jarvis AI send our data to a third party or external system?** No. Jarvis AI deploys directly into your own environment, so your data never leaves your infrastructure or flows into any external system. There is no shared infrastructure, no external data plane, and no external data transmission, and you retain full ownership of your data, AI interactions, and audit logs. **How is Jarvis AI different from a typical cloud AI service in terms of data sovereignty?** Unlike a typical SaaS or shared cloud AI service, Jarvis AI is licensed, customer-hosted software that deploys into your own environment, so there is no shared infrastructure and no external data transmission. You maintain full ownership of your data, AI interactions, and audit logs, which is what gives enterprises the data sovereignty and compliance control they require. **Where can I get Jarvis AI?** Jarvis AI is available on both the AWS Marketplace and the Azure Marketplace, making procurement straightforward for organizations with existing cloud spend commitments. **Where can I deploy Jarvis AI?** Virtually anywhere you run Kubernetes clusters. We natively support AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE). Hybrid and on-premises Kubernetes environments are also supported. **Can Jarvis AI run fully on-premises?** Yes. Jarvis AI can be deployed virtually anywhere you run Kubernetes clusters, including hybrid and on-premises Kubernetes environments. It also natively supports AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE). **What open standards is Jarvis AI built on?** Jarvis AI is built on open standards including the MCP and A2A protocols. This is part of its future-proofing design, so your infrastructure evolves as the AI ecosystem does without ripping and replacing your setup. **How does Jarvis AI control which data and tools an AI interaction can access?** Jarvis AI governs access through native Azure EntraID authentication, RBAC, and granular ACL policies defined per user or team, combined with OAuth-controlled egress. Access control is enforced at the platform level rather than left to individual users, and every AI interaction and agent action is captured in full audit logs. **What kind of audit logging does Jarvis AI provide for compliance?** Jarvis AI provides full audit logs of every AI interaction and agent action, and you retain ownership of those logs within your own infrastructure. Combined with strict data privacy and no external data plane, this supports the data sovereignty and compliance requirements that enterprise customers have. **How do Jarvis Chat and Jarvis Registry work together as a platform?** Jarvis Chat and Jarvis Registry are two fully independent products, but when used together they form a complete enterprise AI platform. Jarvis Chat is a governed multi-LLM chat workspace, while Jarvis Registry is the MCP and agent gateway that connects copilots to enterprise tools through a single governed entry point. Jarvis Chat can connect to Jarvis Registry to discover and invoke agents, while Registry simultaneously serves other clients such as Microsoft Copilot and Claude. Neither product requires the other. **What AI clients does Jarvis Registry support?** Jarvis Registry works with any MCP-compatible AI client, including Microsoft Copilot, GitHub Copilot Chat, Claude Desktop, ChatGPT, VS Code, and Cursor. It serves as a single governed entry point for tool discovery, routing, and context delivery regardless of which AI client your team uses. **How does Jarvis AI handle security and compliance?** Security is built into every layer, not added on. This includes Azure EntraID-native authentication, RBAC, granular ACL policies per user or team, OAuth-controlled egress, full audit logs of every AI interaction and agent action, and strict data privacy with no external data plane. ### Jarvis Chat **What is Jarvis Chat?** Jarvis Chat is an enterprise chat interface that gives your team access to multiple AI models through one secure, governed workspace. It is built for organizations that need control over who can use AI, what data it can access, and how it behaves — all without sacrificing usability. **What makes Jarvis Chat unique?** Jarvis Chat is built around security, control, and future-proofing. It deploys directly into your environment, meaning your data never leaves your infrastructure or flows into any external system. Every chat interaction is governed through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress. It is also built on open standards like MCP and A2A protocols, so your setup evolves as the AI ecosystem does — without ripping and replacing. **Is Jarvis Chat a SaaS product?** No. Jarvis Chat is licensed, customer-hosted software. We intentionally avoided the SaaS model because enterprise customers require strict data sovereignty and compliance. You maintain full ownership of your data, chat interactions, and audit logs — with no shared infrastructure and no external data transmission. **Is Jarvis Chat a standalone product?** Yes. Jarvis Chat works fully on its own. It can connect to your existing MCP servers, RAG pipelines, or third-party integrations independently. It can also be paired with Jarvis Registry for a more complete enterprise AI platform, but that is entirely optional. **Can Jarvis Chat connect to our own MCP servers or RAG pipelines without Jarvis Registry?** Yes. Jarvis Chat works fully on its own and can connect to your existing MCP servers, RAG pipelines, or third-party integrations independently. Pairing it with Jarvis Registry for a more complete enterprise AI platform is entirely optional. **What is the difference between Jarvis Chat and Jarvis Registry?** Jarvis Chat is an enterprise chat interface that gives your team access to multiple AI models through one secure, governed workspace, while Jarvis Registry is an enterprise MCP and Agent Gateway that connects any AI copilot to your enterprise tools through a single governed entry point. They are two fully independent products, but when used together they form a complete enterprise AI platform. **Where can I get Jarvis Chat?** Jarvis Chat is available on both the AWS Marketplace and the Azure Marketplace, making procurement straightforward for organizations with existing cloud spend commitments. **Where can I deploy Jarvis Chat?** Virtually anywhere you run Kubernetes clusters. We natively support AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE). Hybrid and on-premises Kubernetes environments are also supported. **Can Jarvis Chat run fully on-premises?** Yes. Jarvis Chat can be deployed virtually anywhere you run Kubernetes clusters, including hybrid and on-premises Kubernetes environments. It natively supports AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE) as well. **Does Jarvis Chat send our data to a third-party AI provider or external system?** No. Jarvis Chat deploys directly into your environment, so your data never leaves your infrastructure or flows into any external system. It is licensed, customer-hosted software with no shared infrastructure and no external data transmission, and built-in guardrails let you ensure sensitive information is never exposed to AI models or external systems. **How does Jarvis Chat handle access control?** Jarvis Chat integrates with your existing enterprise identity provider and supports SSO, RBAC, and SAML/OAuth. You have precise control over which users and groups can access specific AI models, tools, and knowledge bases — enforced at the platform level, not left to individual users. **How do you control which employees can use specific AI models in Jarvis Chat?** Jarvis Chat integrates with your existing enterprise identity provider and supports SSO, RBAC, and SAML/OAuth, giving you precise control over which users and groups can access specific AI models, tools, and knowledge bases. These controls are enforced at the platform level rather than left to individual users. **How does Jarvis Chat protect sensitive data?** Jarvis Chat includes built-in guardrails that match your organization's data policies. You can enable PII detection, define DLP (Data Loss Prevention) rules, and set custom privacy policies to ensure sensitive information is never exposed to AI models or external systems. **How does Jarvis Chat prevent PII or sensitive data from being sent to AI models?** Jarvis Chat includes built-in guardrails that match your organization's data policies. You can enable PII detection, define DLP (Data Loss Prevention) rules, and set custom privacy policies so sensitive information is never exposed to AI models or external systems. **Which AI models does Jarvis Chat support?** Jarvis Chat integrates with OpenAI, Anthropic, AWS Bedrock, and more. You can switch between models, compare outputs, and route requests to the right provider — all from a single interface. As new models emerge, you can add them without changing your underlying setup. **Can Jarvis Chat run multiple LLMs side by side so we can compare model outputs?** Yes. Jarvis Chat integrates with OpenAI, Anthropic, AWS Bedrock, and more, and lets you switch between models, compare their outputs, and route requests to the right provider from a single interface. As new models emerge, you can add them without changing your underlying setup. **Can we embed Jarvis Chat into our own applications?** Yes. Jarvis Chat comes with a JavaScript SDK, Web Components, and iFrame support, allowing you to embed it directly into your existing portals, internal tools, or custom applications. Your teams get a governed AI experience without leaving the products they already use. **How do you embed Jarvis Chat inside an existing internal portal or web application?** Jarvis Chat comes with a JavaScript SDK, Web Components, and iFrame support, letting you embed it directly into your existing portals, internal tools, or custom applications. Your teams get a governed AI experience without leaving the products they already use. **Can Jarvis Chat connect to our internal knowledge base?** Yes. Jarvis Chat includes an enterprise knowledgebase feature that lets you upload documents and connect internal data sources. Your team can then ask questions in natural language and get accurate, AI-generated answers grounded in your own organizational data — not generic internet content. **Can Jarvis Chat answer questions using our own internal documents instead of generic internet content?** Yes. Jarvis Chat includes an enterprise knowledgebase feature that lets you upload documents and connect internal data sources. Your team can then ask questions in natural language and get accurate, AI-generated answers grounded in your own organizational data rather than generic internet content. **Does Jarvis Chat support AI agents and automation?** Yes. Jarvis Chat supports AI-driven agents that can automate routine tasks, orchestrate multi-step workflows, and handle complex processes end-to-end. This allows your teams to focus on higher-value work while agents handle the repetitive work in the background. **Can Jarvis Chat automate multi-step workflows with AI agents?** Yes. Jarvis Chat supports AI-driven agents that can automate routine tasks, orchestrate multi-step workflows, and handle complex processes end-to-end. This lets your teams focus on higher-value work while agents handle the repetitive work in the background. ### Jarvis Registry **What is Jarvis Registry?** Jarvis Registry is an enterprise MCP and Agent Gateway that connects any AI copilot to your enterprise tools through a single, governed entry point. It handles centralized discovery, routing, authentication, and governance for all MCP servers and AI agents — giving your organization full control over what AI can access and how. **Does Jarvis Registry have to be used with Jarvis Chat?** No. Jarvis Registry is a fully independent product. It integrates with any MCP-compatible AI client out of the box and does not require Jarvis Chat to operate. That said, when paired with Jarvis Chat, the two form a complete enterprise AI platform with end-to-end governance. **Is Jarvis Registry a SaaS product?** No. Jarvis Registry is licensed, customer-hosted software. It deploys directly into your environment so your data, tool access, and agent interactions never leave your infrastructure. There is no shared infrastructure and no external data transmission. **Can Jarvis Registry run fully on-premises or in our own cloud?** Yes. Jarvis Registry is licensed, customer-hosted software that deploys directly into your environment, and it runs virtually anywhere you operate Kubernetes clusters. ASCENDING natively supports AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE), as well as hybrid and on-premises Kubernetes environments. **Does Jarvis Registry send our data to a third party or external service?** No. Jarvis Registry deploys directly into your environment so your data, tool access, and agent interactions never leave your infrastructure, with no shared infrastructure and no external data transmission. Sensitive credentials and secrets are decrypted only within your own environment and are never exposed to or stored in any external system. **Where can I get Jarvis Registry?** Jarvis Registry is available on both the AWS Marketplace and the Azure Marketplace, making procurement straightforward for organizations with existing cloud spend commitments. **Where can I deploy Jarvis Registry?** Virtually anywhere you run Kubernetes clusters. We natively support AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE). Hybrid and on-premises Kubernetes environments are also supported. **Which AI copilots does Jarvis Registry support?** Jarvis Registry works with any MCP-compatible AI client. This includes Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, Jarvis Chat, and ChatGPT. One registry, every client — no duplicate configuration required per tool or per team. **How is Jarvis Registry different from an API gateway?** Jarvis Registry is an enterprise MCP and Agent Gateway purpose-built as the control layer between AI copilots and your enterprise tools, rather than a generic API gateway. It centralizes MCP tool discovery and dynamic routing, integrates with your identity provider through OAuth and SAML, enforces RBAC and ACL governance, and keeps audit trails for every AI tool call. Instead of each copilot connecting directly to each tool, all copilot-to-tool traffic flows through one governed layer with consistent access controls and audit trails. **How does Jarvis Registry connect AI copilots to enterprise tools?** Jarvis Registry acts as a universal gateway between your AI copilots and your enterprise tools — including Jira, Confluence, Slack, Google Drive, Gmail, PostgreSQL, Snowflake, GitHub, Docker, and AWS. Instead of each copilot connecting directly to each tool, all traffic flows through a single governed layer with consistent access controls and audit trails. **Do I need to manually configure tools for each AI client?** No. Jarvis Registry includes intelligent auto-discovery that dynamically identifies available tools, resources, and skills based on context and permissions. Copilots find the right tools automatically — no manual configuration needed per client. **How does Jarvis Registry decide which tools an AI copilot can see and use?** Jarvis Registry uses intelligent auto-discovery that dynamically identifies available tools, resources, and skills based on context and permissions, so copilots find the right tools automatically without manual per-client configuration. Access is governed by RBAC roles and per-user, per-team, or per-agent ACL policies enforced at the tool level on every invocation, so users only see and invoke the tools they are authorized for. **How does Jarvis Registry handle governance and security?** Jarvis Registry enforces fine-grained access controls at the tool level. It integrates with your enterprise identity provider through OAuth and SAML, supports RBAC (Role-Based Access Control), and allows you to define ACL (Access Control List) policies per user, team, or agent. Every interaction is governed — not just at login, but at every tool call. **Does Jarvis Registry integrate with our existing identity provider and SSO?** Yes. Jarvis Registry integrates with your enterprise identity provider through OAuth and SAML and supports enterprise SSO authentication. Access is then governed by RBAC roles and ACL policies enforced at every tool call, not just at login. **What is the difference between RBAC and ACL in Jarvis Registry?** RBAC controls access based on a user's role within the organization — for example, a developer role may have access to GitHub and Docker tools while a finance role does not. ACL provides a more granular layer on top of that, allowing you to define specific allow or deny rules for individual users, groups, or agents down to the tool level. Together they give you both scalable and precise control over AI access. **Does Jarvis Registry support OAuth?** Yes. Jarvis Registry has native OAuth integration for both inbound authentication from AI clients and outbound access to enterprise tools and services. This means every connection — whether from a copilot into the registry or from the registry out to a tool — is properly authenticated and authorized through your existing identity infrastructure. **How does Jarvis Registry handle encryption?** Jarvis Registry encrypts data in transit using TLS for all communication between AI clients, the gateway, and connected tools. Sensitive credentials, tokens, and secrets used for tool connections are encrypted at rest. Decryption occurs only within your own environment — no keys or secrets are ever exposed to or stored in any external system. **What visibility does Jarvis Registry provide into AI interactions?** Jarvis Registry provides real-time monitoring, analytics, and complete audit trails for every AI interaction. You can see what tools are being called, by whom, at what time, and with what context. Anomaly detection and alerting are also built in so your team can catch unexpected behavior early. **Can Jarvis Registry detect unusual or unexpected AI behavior?** Yes. Jarvis Registry provides real-time monitoring, analytics, and complete audit trails for every AI interaction, so you can see what tools are called, by whom, at what time, and with what context. Anomaly detection and alerting are built in so your team can catch unexpected behavior early. **Does Jarvis Registry maintain audit logs?** Yes. Every agent action, tool call, and routing decision is logged. Audit logs are stored within your environment and can be integrated with your existing logging and SIEM tooling. This supports compliance requirements across regulated industries including finance, healthcare, and government. ### MCP Gateway **What is an MCP gateway?** An MCP gateway is the control and enforcement layer between AI clients and MCP servers. It centralizes discovery, authentication, policy checks, routing, and auditing for every MCP tool call. Instead of configuring each copilot directly against each MCP server, you expose one governed endpoint and enforce consistent policy for all clients. **How is the MCP Gateway different from the Agent Gateway?** The MCP Gateway focuses on tool, resource, and prompt invocation against MCP servers. The Agent Gateway focuses on autonomous agents and agent-to-agent orchestration. Both are part of Jarvis Registry and share identity, policy, and observability controls, but they operate on different runtime objects and invocation models. **Where can enterprises procure the Jarvis MCP Gateway?** Jarvis Registry, which provides the enterprise MCP gateway and MCP server registry, is available on both the AWS Marketplace and the Azure Marketplace. This makes procurement straightforward for organizations with existing cloud spend commitments. **Can Jarvis Registry's MCP Gateway run fully on-premises or inside our own cloud?** Yes. Jarvis Registry is licensed, customer-hosted software that deploys directly into your environment, virtually anywhere you run Kubernetes clusters. It natively supports AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE), and hybrid and on-premises Kubernetes environments are also supported. **Does the Jarvis MCP Gateway send our data to a third party or external service?** No. Jarvis Registry is licensed, customer-hosted software with no shared infrastructure and no external data transmission, so your data, tool access, and agent interactions never leave your infrastructure. Tokens and secrets are encrypted at rest and used server-side within your own environment, and decryption occurs only inside your environment. **Do I need to redeploy MCP servers to use Jarvis Registry?** No. MCP federation imports existing MCP servers from AWS AgentCore and Azure AI Foundry into the Jarvis catalog without redeployment. Servers continue running in their source environment while Jarvis applies unified RBAC, ACL, and audit policy at the gateway layer. **How do I import existing AWS AgentCore and Azure AI Foundry MCP servers without redeploying them?** Jarvis MCP federation imports existing MCP servers from AWS AgentCore and Azure AI Foundry into the Jarvis catalog without redeployment. Jarvis connects to each provider, discovers MCP servers and their capabilities, and syncs them into one governed namespace, while the servers keep running in their source environment. Jarvis then applies unified RBAC, ACL, and audit policy at the gateway layer. **How does multi-cloud MCP federation work in practice?** Jarvis connects to each provider, discovers MCP servers and capabilities, and syncs them into one governed namespace. Each imported server is then exposed through the same gateway endpoint used by native servers. From the client perspective, cloud origin is transparent. Discovery and invocation behavior stays consistent across self-hosted, AWS, and Azure MCP servers. **Does the cloud origin of an MCP server affect how AI clients discover and call it through Jarvis?** No. Once federated, each imported MCP server is exposed through the same gateway endpoint used by native servers, so the cloud origin is transparent to the client. Discovery and invocation behavior stays consistent across self-hosted, AWS, and Azure MCP servers. **Does the MCP Gateway support auth elicitation?** Yes. Jarvis supports auth elicitation flows so MCP clients can be prompted to complete required authentication when a downstream server requires user consent or refreshed credentials. This allows secure per-user authorization without exposing raw credentials to the client or bypassing enterprise identity policy. **What happens when a downstream MCP server requires user consent or refreshed credentials mid-session?** Jarvis supports auth elicitation flows, so MCP clients can be prompted to complete required authentication when a downstream server needs user consent or refreshed credentials. This enables secure per-user authorization without exposing raw credentials to the client or bypassing enterprise identity policy. Silent refresh and revocation-aware handling keep access stable while maintaining a least-privilege posture. **Does Jarvis support OAuth 2.1 resource indicators (RFC 8707)?** Yes. The MCP Gateway validates resource indicators for token scope binding so a token intended for one MCP server cannot be replayed against another. Jarvis enforces PKCE and standards-based OAuth behavior for inbound and outbound flows, including per-user token lifecycle controls. **How does the Jarvis MCP Gateway prevent a token issued for one MCP server from being replayed against another?** The MCP Gateway validates OAuth 2.1 resource indicators (RFC 8707) for token scope binding, so a token intended for one MCP server cannot be replayed against another. Jarvis also enforces PKCE and standards-based OAuth behavior for both inbound and outbound flows, including per-user token lifecycle controls. **How are downstream MCP credentials secured?** Tokens and secrets are encrypted at rest and used server-side within your environment. Credentials are isolated per user and per downstream MCP server. Silent refresh and revocation-aware handling ensure stable access while maintaining least-privilege posture and auditability. **How does access control work for MCP tools?** Jarvis applies RBAC and ACL policy at tool level on every invocation. Users and service identities see only the tools they are authorized to discover and invoke. Policy decisions are enforced at runtime and captured in the audit stream for compliance review. **How do I govern which MCP tools an individual employee or service identity can invoke?** Jarvis applies RBAC and ACL policy at the tool level on every invocation, so users and service identities see only the tools they are authorized to discover and invoke. You can scope policy by role, group, environment, server, and individual tool actions, and policy decisions are enforced at runtime and captured in the audit stream for compliance review. **Can I enforce different policies by team or environment?** Yes. You can scope policy by role, group, environment, server, and individual tool actions. This supports strict separation across dev, staging, and production. Central policy management avoids drift and keeps enforcement consistent across every connected copilot. **What observability data does the MCP Gateway provide?** Jarvis emits trace and audit telemetry for discovery and invocation events, including user identity context, policy decision, target server, and result status. Telemetry is OTLP-compatible and can be forwarded to Datadog, Grafana, and other enterprise observability backends. **Can I forward Jarvis MCP Gateway telemetry to Datadog or Grafana?** Yes. The MCP Gateway emits trace and audit telemetry for discovery and invocation events, including user identity context, policy decision, target server, and result status. This telemetry is OTLP-compatible and can be forwarded to Datadog, Grafana, and other enterprise observability backends. **Why might an MCP client fail to invoke a tool?** The most common causes are missing policy scope, expired downstream credentials, unsupported auth state, or schema mismatches between client input and tool contract. Jarvis surfaces policy and auth failure details in logs so teams can quickly determine whether the issue is access, token state, or request format. ### Agent Gateway **What is an agent registry?** An agent registry is the authoritative catalog where AI agents are registered, described by their skills and capabilities, and exposed through a secure, governed gateway. It is the directory service for your agentic infrastructure — what DNS does for hostnames, the agent registry does for AI agents. Without a central registry, agents proliferate as shadow AI across teams and clouds with no visibility into who can use them, what they can do, or whether they are safe to invoke. Jarvis Registry solves this with a single governed catalog that spans self-hosted, AWS-federated, and Azure-federated agents. **What is an agent gateway?** An agent gateway is the runtime endpoint through which AI copilots and applications invoke registered agents. Rather than each copilot connecting directly to each agent, all traffic flows through the gateway — which enforces authentication, applies RBAC and ACL policies, routes the request to the correct backend, and records the event for observability. Jarvis Registry provides both the registry and the gateway in a single platform, deployed inside your own infrastructure. **What is the difference between an agent gateway and an agent registry?** The agent registry is the catalog — where agents are discovered, described, and governed. The agent gateway is the runtime — the single secure endpoint through which copilots invoke those agents. Jarvis Registry provides both in one platform: a registry that maintains the catalog and policies, and a gateway endpoint that enforces them at request time. From a copilot perspective there is one URL; from an admin perspective there is one console to govern everything. **How do you prevent shadow AI agents from proliferating across teams and clouds?** Jarvis Registry solves shadow AI by providing a single governed catalog where every agent is registered, described by its skills and capabilities, and exposed through a secure, governed gateway. Without a central registry, agents proliferate as shadow AI across teams and clouds with no visibility into who can use them, what they can do, or whether they are safe to invoke. Jarvis Registry spans self-hosted, AWS-federated, and Azure-federated agents in one place. **Do I need to redeploy AWS or Azure agents to use Jarvis Registry?** No. Federation works against your existing AgentCore and AI Foundry deployments. Agents continue to run where they already are — Jarvis Registry imports their metadata into the local catalog and proxies invocations through the gateway, applying RBAC and ACL policies on top of the existing deployment. There is no agent-side code change required. **How does AWS AgentCore federation work?** Jarvis Registry connects to your AgentCore deployment using cross-account IAM role assumption. Once configured, Jarvis performs an on-demand sync to discover all agents in the target AgentCore workspace. Discovered agents appear in the registry catalog and are immediately subject to your RBAC and ACL governance policies. Copilots invoke them through the same Jarvis gateway endpoint as every native agent — the federation source is transparent to the client. **How does Azure AI Foundry federation work?** Jarvis Registry connects to Azure AI Foundry using your tenant credentials, scoped to the subscription and resource group you specify. Synced agents are imported into the local catalog and governed by the same identity and access policies as all other registered agents — RBAC scopes, per-user ACLs, and audit logging apply uniformly regardless of whether an agent runs in Azure, AWS, or on-premises. **Can Jarvis Registry run fully on-premises without sending data to a third party?** Yes. Jarvis Registry is licensed, customer-hosted software that deploys into your own Kubernetes environment such as AWS EKS, Azure AKS, or GKE, and hybrid or on-premises Kubernetes is also supported. All agent metadata, access control policies, audit logs, and invocation telemetry remain inside your infrastructure, with no external data plane and no shared cloud service that receives your data. **What agentic workflow models does Jarvis Registry support?** Jarvis Registry supports two distinct orchestration models. Manual drag-and-drop pipeline: a visual canvas where you connect registered agents in sequence or parallel to define a deterministic workflow — best for compliance-sensitive processes where every step must be auditable and predictable. LLM-driven orchestration: you define a curated pool of permitted agents and provide a task; an LLM reasons over the task, selects the appropriate agents from the pool, and sequences execution dynamically. The LLM operates only within the approved agent pool, so governance is maintained without constraining the model reasoning. Both models share the same governance layer, observability pipeline, and security posture. **Does Jarvis Registry let an LLM choose which AI agents to run on its own, and is that safe?** Yes. With Jarvis Registry's LLM-driven orchestration, you define a curated pool of permitted agents and provide a task. An LLM reasons over the task, selects the appropriate agents from the pool, and sequences execution dynamically. Because the LLM operates only within the approved agent pool, governance is maintained without constraining the model reasoning. **Can I mix manual and LLM-driven steps in the same workflow?** Yes. You can define a pipeline where certain stages are deterministic — a fixed agent sequence or a human approval gate — and others delegate to an LLM sub-orchestrator over a defined agent pool. This lets you enforce strict control at sensitive steps while giving the LLM flexibility over intermediate processing where determinism is less critical. **Can I require a human approval step inside an automated agent workflow in Jarvis Registry?** Yes. You can define a pipeline where certain stages are deterministic, such as a fixed agent sequence or a human approval gate, and others delegate to an LLM sub-orchestrator over a defined agent pool. This lets you enforce strict control at sensitive steps while giving the LLM flexibility over intermediate processing where determinism is less critical. **Why would I use a deterministic drag-and-drop agent pipeline instead of LLM orchestration in Jarvis Registry?** Jarvis Registry's manual drag-and-drop pipeline is a visual canvas where you connect registered agents in sequence or parallel to define a deterministic workflow. It is best for compliance-sensitive processes where every step must be auditable and predictable, whereas LLM-driven orchestration is better when you want the model to select and sequence agents dynamically. Both models share the same governance layer, observability pipeline, and security posture. **What does the agent security scan check for?** Every agent published to the registry passes through an automated security scan before it can be invoked. The scan covers prompt injection patterns in system prompts and capability declarations, capability misuse risks where agents declare access to tools or data beyond their intended scope, and policy compliance against custom rules you define per environment. The scan acts as a publish gate — an agent cannot be invoked until it passes. Re-scan triggers automatically whenever an agent card is updated, ensuring no previously approved agent can silently introduce a risk through an update. **What happens when an agent is updated after it has already passed Jarvis Registry's security scan?** Re-scan triggers automatically whenever an agent card is updated, ensuring no previously approved agent can silently introduce a risk through an update. The security scan acts as a publish gate, so the updated agent cannot be invoked until it passes the scan, which covers prompt injection patterns, capability misuse risks, and policy compliance against custom rules you define per environment. **How does access control work across teams and federated agents?** Jarvis Registry integrates with your enterprise identity provider such as Azure EntraID, Okta, or Auth0 via OIDC and SAML. Access is governed at two levels: RBAC scopes that control which agents a user or group can discover and invoke, and ACL policies that provide per-agent access control lists for specific users, teams, or service identities. Both layers apply uniformly to native agents, AWS AgentCore-federated agents, and Azure AI Foundry-federated agents. A user only sees and can invoke what they are explicitly authorized for, regardless of where the agent runs. **Which identity providers does the Jarvis Registry agent gateway work with?** Jarvis Registry integrates with your enterprise identity provider such as Azure EntraID, Okta, or Auth0 via OIDC and SAML. Access is governed through RBAC scopes that control which agents a user or group can discover and invoke, plus ACL policies that provide per-agent access control lists for specific users, teams, or service identities. **Does access control in Jarvis Registry apply the same way to agents running in AWS and Azure as to local agents?** Yes. Both the RBAC and ACL layers apply uniformly to native agents, AWS AgentCore-federated agents, and Azure AI Foundry-federated agents. A user only sees and can invoke what they are explicitly authorized for, regardless of where the agent runs. **Does Jarvis Registry store or transmit data externally?** No. Jarvis Registry is licensed, customer-hosted software that deploys into your own Kubernetes environment such as AWS EKS, Azure AKS, or GKE. All agent metadata, access control policies, audit logs, and invocation telemetry remain inside your infrastructure. There is no external data plane and no shared cloud service that receives your data. **What does the built-in OTEL collector capture?** The integrated OpenTelemetry collector instruments every layer of the agent gateway without requiring any changes to your agents. It captures distributed traces from copilot request through gateway routing to agent response, invocation metrics such as latency, error rates, token usage, and throughput per agent, per user, and per team, workflow execution events for both manual and LLM-driven pipelines, and access decisions including denials for compliance reporting. All telemetry exports via OTLP to any compatible backend, including Datadog, Grafana, Honeycomb, AWS CloudWatch, Azure Monitor, or self-hosted stacks like Jaeger and Prometheus. **Which observability backends can the Jarvis Registry agent gateway export telemetry to?** The integrated OpenTelemetry collector exports all telemetry via OTLP to any compatible backend, including Datadog, Grafana, Honeycomb, AWS CloudWatch, Azure Monitor, or self-hosted stacks like Jaeger and Prometheus. It captures distributed traces, invocation metrics such as latency, error rates, token usage, and throughput, workflow execution events, and access decisions, without requiring any changes to your agents. **Do I have to instrument my agents to get tracing in Jarvis Registry?** No. The integrated OpenTelemetry collector instruments every layer of the agent gateway without requiring any changes to your agents. It captures distributed traces from the copilot request through gateway routing to the agent response, along with invocation metrics per agent, per user, and per team. **Does Jarvis Registry maintain audit logs (agent gateway)?** Yes. Every agent invocation, workflow step, tool call, and access decision is logged. Audit logs are stored within your environment and can be integrated with your existing logging and SIEM tooling. This supports compliance requirements across regulated industries including finance, healthcare, and government. Logs are retained inside the registry independently of any OTLP export destination, so compliance reporting is available even before you connect an observability backend. **Are Jarvis Registry audit logs available before I connect an observability backend?** Yes. Every agent invocation, workflow step, tool call, and access decision is logged, and logs are retained inside the registry independently of any OTLP export destination. This means compliance reporting is available even before you connect an observability backend, and audit logs can be integrated with your existing logging and SIEM tooling. **Does Jarvis Registry support agent-to-agent (A2A) orchestration with governance?** Yes. Jarvis Registry is built on open standards including the MCP and A2A protocols, and the agent gateway routes invocations to registered agents while enforcing authentication and applying RBAC and ACL policies. All traffic flows through the gateway, which records each event for observability rather than letting copilots connect directly to each agent. **How does Jarvis Registry relate to Jarvis Chat?** The two products are fully independent and can be used separately. Jarvis Registry is the agent gateway and catalog — it serves any MCP-compatible copilot. Jarvis Chat is a governed multi-LLM chat workspace for enterprise teams. When used together they form a complete enterprise AI platform: Jarvis Chat connects to Jarvis Registry to discover and invoke agents, while Registry simultaneously serves Microsoft Copilot, Claude, VS Code, and any other client your teams use. Neither product requires the other. ### Agent Registry **What is the Jarvis Agent Registry and what problem does it solve?** The Agent Registry is the authoritative catalog for every AI agent and MCP server in your enterprise. It solves the governance gap that emerges when teams start deploying autonomous agents independently: without a registry, there is no central record of what agents exist, who owns them, what they are permitted to do, or which version is active. Invocations happen without policy enforcement, audit trails are incomplete, and duplicate agents proliferate across teams. The registry provides a single source of truth that the Agent Gateway reads from at runtime. Every agent is registered with its identity, owner team, capability schema, access policy, and version — before it can be invoked by any workflow or copilot. **What is an AI agent registry and why do enterprises need one?** An AI agent registry is the authoritative catalog for every AI agent and MCP server in your enterprise, recording each agent's identity, owner team, capability schema, access policy, and version before it can be invoked. Enterprises need one because deploying autonomous agents without a central catalog creates a governance gap — no record of what agents exist, who owns them, what they're permitted to do, or which version is active. The Jarvis Agent Registry provides a single source of truth that the Agent Gateway reads from at runtime to enforce policy on every invocation. **What is the difference between the agent registry and the agent gateway?** The registry is the catalog plane — it stores what agents exist, what they can do, who owns them, and who is permitted to invoke them. The gateway is the data plane — it enforces the registry policy at the moment of every invocation. The registry does not sit in the request path; the gateway does. A useful mental model: the registry is the rulebook, the gateway is the enforcer. You update the rulebook once; every enforcement point reflects the change immediately. Neither is complete without the other — the registry without the gateway is documentation, and the gateway without the registry is a proxy with no policy context. **Does the registry sit in the request path when an agent is invoked?** No. The registry is a catalog and policy store — it is consulted at registration time and when policies change, but it is not in the hot path of every invocation. The Agent Gateway sits in the request path and enforces the registry policy in real time using a local policy cache that is invalidated immediately on any registry update. This design means registry updates do not add latency to invocations, and the registry can be updated, versioned, and audited independently of the gateway's request handling. **Do I need to redeploy my AWS or Azure agents to register them?** No. The federation layer imports agents from AWS AgentCore and Azure AI Foundry into the registry catalog without redeployment. Federated agents continue running in their original environment — the registry stores a reference and a capability snapshot, and the gateway routes to them through the federation endpoint. Once federated, these agents inherit the same RBAC, ACL policies, versioning, and audit trail as natively registered agents. From the perspective of any workflow or copilot connecting through the gateway, a federated AWS agent and a natively registered agent are indistinguishable. **What cloud providers are supported for federation today?** The current federation layer supports AWS AgentCore and Azure AI Foundry out of the box. Both use the federation tab in the Jarvis Registry UI to configure the connection — AWS via IAM role assumption, Azure via service principal with Azure AD SSO. The federation architecture is protocol-based rather than provider-specific, so additional providers can be added through the external providers API. Contact us if you have a specific provider requirement. **If a federated agent is updated in AWS or Azure, does the registry reflect the change automatically?** The registry maintains a synced capability snapshot for each federated agent. Changes to the agent in its source environment — updated tool definitions, changed endpoint, new version — are detected on the next sync cycle and reflected in the registry catalog. The sync interval is configurable; the default is 15 minutes, and you can trigger a manual sync at any time from the federation tab. Any capability change that triggers a re-scan will hold the agent in a pending-review state until the scan passes, even for federated agents. This prevents a silently updated external agent from bypassing your security gate. **What does the security scan at registration actually check?** The registration pipeline runs three checks before an agent becomes active in the catalog. Capability declaration scan: validates the agent schema against allowed capability patterns; detects over-broad tool claims, missing required fields, and schema constructs that could mislead an orchestrator about what the agent actually does. Prompt injection scan: detects injection payloads embedded in the agent's name, description, or capability fields — a malicious actor registering an agent with injected instructions in its description is a real attack vector, and this check blocks it at the publish gate. Policy compliance check: verifies the agent's declared behavior does not conflict with active enterprise policy rules; agents fail if they claim capabilities that are restricted or require explicit approval for your organization. Agents remain inactive until all three pass, and any update to the agent card re-triggers the full pipeline. **How does Jarvis Registry block prompt injection at agent registration?** Jarvis Registry runs a prompt injection scan that detects injection payloads embedded in an agent's name, description, or capability fields, blocking a malicious actor who registers an agent with injected instructions at the publish gate. This runs alongside a capability declaration scan and a policy compliance check, and an agent remains inactive until all three pass. Any update to the agent card re-triggers the full pipeline so a silent update cannot bypass the security gate. **How quickly does a policy change in the registry reach the gateway?** Policy propagation from registry to gateway enforcement is real-time — not a sync interval or cache TTL. When you revoke a user's access or deprecate an agent version, the gateway reflects the change immediately on the next invocation attempt. This is a security requirement, not a performance optimization. The window between a policy change and its enforcement is a security exposure — an attacker who has been granted access that is subsequently revoked must find that access blocked immediately, not after a cache expires. **Can an agent be invoked if it hasn't passed the security scan?** No. The registry enforces a publish gate — agents in pending or scan-failed state are not visible to the gateway routing layer and cannot be invoked. The gateway returns a 404 Not Found for any invocation targeting an agent that has not passed its scan and been explicitly published. This applies to both newly registered agents and agents whose card was updated — a capability change puts the agent back into pending until the re-scan completes, preventing a silent update from bypassing the security gate. **How does access policy work — RBAC, ACL, or both?** The registry supports both, applied in layers. RBAC scopes define broad permissions by role — for example, sre-engineer can invoke all agents in the ops namespace. ACL entries layer on top for per-agent, per-identity fine-grained control — for example, blocking a specific team from a specific agent even if their role would otherwise permit it. Access policy objects are defined in the registry and propagated to the gateway in real time. The gateway evaluates both layers on every invocation: role first, then per-resource ACL overrides. Deny always wins over allow when there is a conflict. **Which identity providers are supported for authentication?** The Identity & Access Layer supports any OIDC-compliant identity provider. Tested integrations include Azure EntraID, Okta, Auth0, and AWS IAM Identity Center. JWT tokens from your IdP are validated at the gateway; claims are mapped to registry RBAC roles and ACL identities via a configurable claim-mapping policy. Machine-to-machine invocations — orchestrators, CI pipelines, and other agents invoking agents — use OAuth 2.0 client credentials flow with audience-separated JWTs so each agent token cannot be replayed against a different agent. **When an employee leaves the organization, how is their agent access revoked?** Access revocation flows from your IdP — when an account is deprovisioned in Azure EntraID or Okta, their OIDC tokens stop being issued and existing tokens expire naturally. For immediate revocation before token expiry, the registry provides a per-identity block list that the gateway checks on every request, bypassing token validity entirely. The revoked identity is also marked in the registry ACL audit log so there is a permanent record showing when access was removed and which agent resources were affected. This supports offboarding compliance requirements without any manual policy cleanup in individual agent configs. **What happens to active workflows when I deprecate an agent version?** Deprecating a version in the registry immediately stops the gateway from routing new invocations to it. Active workflows automatically route to the current approved version — no workflow redeploys, no orchestrator config changes needed. This is the blast radius control pattern: one registry operation immediately propagates to all active workflows. If a version needs to be deprecated urgently due to a defect or security issue, the single registry action is sufficient to stop exposure across every consumer. **Can I roll back to a previous agent version if the current one has an issue?** Yes. The registry maintains the full version history for each registered agent. Promoting a previous version back to current status re-activates it immediately — the gateway reflects the change without any config update on the workflow or orchestrator side. The rollback action itself is recorded in the audit trail with the operator identity, timestamp, and the previous state — supporting post-incident review and compliance documentation. **How do I handle multiple teams running different versions of the same agent?** The registry supports version-pinning at the access policy level. A workflow or team can be bound to a specific agent version via their ACL entry — they continue receiving that version even after a new one becomes the org-wide current. This allows gradual rollouts: new version active for most consumers, while a team that has not migrated yet stays pinned to the previous one. Version pins are tracked in the registry and visible in the audit trail. The registry surfaces a warning when a pinned team is running a deprecated version, prompting migration without forcing a breaking change. **How does the registry support autonomous (LLM-driven) workflows?** Autonomous workflows — where the LLM selects agents at runtime — need a bounded agent pool, not an open catalog. The registry defines which agents an LLM may consider for a given workflow, and the gateway enforces that boundary at invocation time. The LLM cannot reach outside the approved set, regardless of what it decides to invoke. Without this constraint, autonomous means unconstrained. A misconfigured or adversarially prompted LLM could invoke any reachable agent. The registry provides the explicit allowlist that makes autonomous safe enough to deploy in production. **Can the registry help prevent prompt injection attacks in agentic workflows?** Yes, at two layers. First, the registration security scan detects injection payloads in agent capability declarations — a malicious agent trying to hijack an LLM behavior by embedding instructions in its description is blocked at publish time. Second, because the registry defines the bounded agent pool available to any given workflow, a prompt injection attack that attempts to redirect an LLM to invoke an unregistered or out-of-scope agent fails at the gateway — the agent simply is not in the allowed set. The registry does not replace runtime content filtering, which belongs in the gateway traffic layer, but it eliminates the catalog-level attack surface. **How does the registry handle agent-to-agent (A2A) invocations?** Agent-to-agent invocations are first-class in the registry. Each agent that can invoke other agents carries its own OAuth client credentials, and its allowed target agents are defined in its ACL entry — an orchestrator agent may invoke the diagnosis agent and the remediation agent, but not the billing agent, even if all four are in the same catalog namespace. The A2A invocation chain is fully visible in the audit trail: each hop records the invoking agent identity, the target agent, the tools called, and the policy version in effect at that moment. This gives you end-to-end traceability for multi-agent workflows without any instrumentation on the agent code itself. ### Governance, Guardrails, Knowledge Base & Agent Flow **What is Jarvis Governed AI?** Jarvis Governed AI is ASCENDING's layer that lets organizations adopt commercial AI models like OpenAI, Anthropic, and AWS Bedrock with enterprise-grade access control, compliance, and AI governance built in. It deploys directly into your environment, so your data never leaves your infrastructure or flows into any external system. Every AI interaction is governed through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress. **Does Jarvis Governed AI support LLM routing across multiple model providers?** Yes. Jarvis Governed AI is built to adopt OpenAI, Anthropic, and AWS Bedrock with LLM routing, so requests can be directed to the appropriate provider from one governed layer. This lets enterprises use multiple models while keeping access control, compliance, and governance consistent across all of them. **Does adopting Jarvis Governed AI require sending enterprise data to a third party?** No. Jarvis deploys directly into your own environment, so your data never leaves your infrastructure or flows into any external system. AI interactions are governed through native Azure EntraID/RBAC, ACL-level access control, and OAuth-governed egress, and Jarvis is licensed, customer-hosted software with no shared infrastructure and no external data transmission. **How many compliance policies does Jarvis AI Guardrails ship with?** Jarvis AI Guardrails include 100+ prebuilt compliance policies for safe, ethical, and compliant AI adoption. Alongside these prebuilt policies, guardrails provide PII redaction, content filtering, topic filtering, RBAC, and real-time alerts. This gives enterprises proactive controls rather than safeguards bolted on after deployment. **Can Jarvis AI redact PII before data reaches an AI model?** Yes. Jarvis AI Guardrails provide PII detection and redaction so sensitive information is controlled before it is exposed to AI models or external systems. You can also define DLP (Data Loss Prevention) rules and custom privacy policies that match your organization's data policies. These guardrails extend to the RAG Knowledge Base as well. **What is the Jarvis RAG Knowledge Base and how does it ground answers?** The Jarvis RAG Knowledge Base uses retrieval-augmented generation to surface company knowledge with GenAI, returning answers grounded in your own organizational data rather than generic internet content. It delivers document citations so responses are traceable to source material, along with vector search and embedded PII guardrails. It is designed for use cases such as legal, sales, and support. **Does the Jarvis Knowledge Base provide citations for AI-generated answers?** Yes. The Jarvis RAG Knowledge Base delivers document citations with its answers, so each AI-generated response can be traced back to the underlying source documents. It pairs these citations with PII guardrails and vector search, surfacing company knowledge that is grounded in your own data instead of generic internet content. **Can the Jarvis RAG Knowledge Base be used by AI agents?** Yes. The Jarvis RAG Knowledge Base includes AI agent integration, so task-driven agents can draw on retrieval-augmented answers grounded in your company documents. Retrieval comes with document citations and PII guardrails, keeping agent responses traceable and compliant. This connects the knowledge base to Jarvis AgentFlow's broader governed agent workflows. **What are Jarvis Agent Flow agents and what can they automate?** Jarvis Agent Flow provides task-driven AI agents for secure, governed automation, with workflow orchestration through Jarvis Registry. The agents orchestrate multi-step workflows, integrate with enterprise tools, and deliver governed AI at scale. This lets teams automate end-to-end processes while keeping AI activity under enterprise governance. **How does Jarvis keep autonomous, LLM-driven agent workflows safe?** With Jarvis Registry's LLM-driven orchestration, you define a curated pool of permitted agents and provide a task; an LLM then selects and sequences agents only from that approved pool. Because the LLM operates within the approved set, governance is maintained without constraining the model's reasoning. For compliance-sensitive processes, Jarvis also offers a deterministic manual drag-and-drop pipeline. ### Ambient AI for Healthcare **What is ambient AI for healthcare, as described by ASCENDING's Jarvis?** ASCENDING describes its healthcare ambient AI as ambient intelligence for clinical care, delivered as HIPAA-compliant AI. It is positioned for clinics, applying Jarvis AI's governed, deploy-in-your-own-environment approach to healthcare settings. The page frames the offering around ambient intelligence and HIPAA compliance rather than a specific feature list. **Is ASCENDING's Jarvis ambient AI for healthcare HIPAA compliant?** Yes. ASCENDING positions its healthcare ambient intelligence offering as HIPAA-compliant AI for clinical care. This aligns with the broader Jarvis approach, where the software deploys directly into your own environment so your data never leaves your infrastructure or flows into any external system. **Does Jarvis send patient or healthcare data to a third party?** No. Jarvis AI is licensed, customer-hosted software that deploys directly into your environment, so your data never leaves your infrastructure or flows into any external system. There is no shared infrastructure and no external data transmission, and you maintain full ownership of your data, AI interactions, and audit logs. This data-sovereignty model underpins ASCENDING's HIPAA-compliant positioning for clinical care. **Can Jarvis AI for healthcare run on-premises or in our own cloud?** Yes. Jarvis AI can be deployed virtually anywhere you run Kubernetes clusters, with native support for AWS (EKS), Microsoft Azure (AKS), and Google Cloud (GKE). Hybrid and on-premises Kubernetes environments are also supported, so a healthcare organization can keep the deployment inside its own infrastructure. **How does Jarvis AI govern and secure access for a healthcare deployment?** Security is built into every layer of Jarvis AI, not added on. This includes Azure EntraID-native authentication, RBAC, granular ACL policies per user or team, OAuth-controlled egress, and full audit logs of every AI interaction and agent action, together with strict data privacy and no external data plane. This supports the compliance needs of sensitive clinical environments. **Where can a clinic procure ASCENDING's Jarvis AI?** Jarvis AI is available on both the AWS Marketplace and the Azure Marketplace, making procurement straightforward for organizations with existing cloud spend commitments. ASCENDING positions the healthcare offering as ambient intelligence for clinical care, delivered as HIPAA-compliant AI. ## Jarvis AI Pages - [Jarvis AI Platform](https://ascendingdc.com/jarvis-ai/): Enterprise AI platform overview - [Jarvis AI FAQ](https://ascendingdc.com/jarvis-ai/faq/): Platform governance, deployment, security, and adoption FAQ - [Jarvis Chat](https://ascendingdc.com/jarvis-ai/jarvis-chat/): Governed multi-LLM enterprise chat workspace - [Jarvis Chat FAQ](https://ascendingdc.com/jarvis-ai/jarvis-chat/faq/): Model access, security, knowledgebase, and deployment FAQ - [Jarvis Registry](https://ascendingdc.com/jarvis-ai/jarvis-registry/): Enterprise MCP & agent gateway - [Jarvis Registry FAQ](https://ascendingdc.com/jarvis-ai/jarvis-registry/faq/): Copilot support, discovery, governance, and observability FAQ - [Agent Registry](https://ascendingdc.com/jarvis-ai/agent-registry/): Governed catalog for AI agents and MCP servers - [Agent Registry FAQ](https://ascendingdc.com/jarvis-ai/agent-registry/faq/): Concepts, federation, security, lifecycle, and access policy FAQ - [Agent Gateway](https://ascendingdc.com/jarvis-ai/agent-gateway/): Runtime gateway for agentic orchestration and federation - [Agent Gateway FAQ](https://ascendingdc.com/jarvis-ai/agent-gateway/faq/): Registration, federation, orchestration, and observability FAQ - [AWS AgentCore Federation](https://ascendingdc.com/jarvis-ai/agent-gateway/agentcore-aifoundry-federation/): Federated AWS AgentCore and Azure AI Foundry agents under one governed layer - [Claude on Amazon Bedrock Governance](https://ascendingdc.com/jarvis-ai/claude-on-amazon-bedrock-governance/): Claude cost control, budget monitoring, and AWS billing governance - [MCP Gateway](https://ascendingdc.com/jarvis-ai/mcp-gateway/): Enterprise MCP gateway and server registry - [MCP Gateway FAQ](https://ascendingdc.com/jarvis-ai/mcp-gateway/faq/): Discovery, federation, auth elicitation, and OAuth FAQ - [Agent Flow](https://ascendingdc.com/jarvis-ai/agent-flow/): Task-driven governed AI agents and workflows - [Governed AI](https://ascendingdc.com/jarvis-ai/governed-ai/): Governed adoption of OpenAI, Anthropic, and AWS Bedrock - [AI Guardrails](https://ascendingdc.com/jarvis-ai/guardrails/): PII redaction, content filtering, RBAC, and 100+ policies - [RAG Knowledge Base](https://ascendingdc.com/jarvis-ai/knowledge-base/): Retrieval-augmented generation with citations and guardrails - [Ambient AI for Healthcare](https://ascendingdc.com/jarvis-ai/healthcare/ambient-ai/): HIPAA-compliant ambient intelligence for clinical care ## More from ASCENDING ASCENDING also delivers cloud, data, security, staffing, and industry-specific consulting beyond the Jarvis AI platform. For complete crawlable route coverage and media discovery: - [LLMs Site Index](https://ascendingdc.com/llms.txt): Complete page map for AI assistants and citation discovery - [XML Sitemap](https://ascendingdc.com/sitemap.xml): Crawlable route inventory for all primary site pages - [Video Sitemap](https://ascendingdc.com/video-sitemap.xml): Crawlable inventory of Jarvis video landing pages Cloud Services: - [AWS Enterprise Partner-Led Support](https://ascendingdc.com/cloud-services/aws-partner-led-support/): Discounted AWS Enterprise Support with a designated TAM, 24x7 coverage, hands-on remediation, FinOps tooling, and an interactive savings calculator - [Cloud Migration and Modernization](https://ascendingdc.com/cloud-service/migration-modernization/): Migrate and modernize workloads across AWS Azure and Google Cloud - [DevOps and GitOps](https://ascendingdc.com/cloud-service/devops-gitops/): CI/CD automation infrastructure as code and faster release delivery - [AWS EKS Kubernetes](https://ascendingdc.com/cloud-service/aws-eks-kubernetes/): Build and optimize Amazon EKS clusters for performance and cost - [AWS Services and Serverless](https://ascendingdc.com/cloud-service/aws-services-serverless/): Serverless architecture and Lambda delivery for scalable cloud operations - [Data Analytics](https://ascendingdc.com/cloud-service/data-analytics/): Build data pipelines and BI dashboards for actionable insights - [Security and Governance](https://ascendingdc.com/cloud-service/security-governance/): Apply security controls across cloud data and operational lifecycles - [IT Staffing Solutions](https://ascendingdc.com/cloud-service/it-staffing-solutions/): Contract and direct-hire IT staffing for critical technology roles - [Cloud IT Training](https://ascendingdc.com/cloud-service/training-for-success/): Instructor-led and self-paced cloud training for team enablement Data and Cloud Solutions: - [Digital Transformation](https://ascendingdc.com/services/digital-transformation/): Integrate digital technology across operations to accelerate business outcomes - [Data Integration](https://ascendingdc.com/services/data-integration/): Collect process and unify business data into analytics-ready systems - [Data Lake and Warehouse](https://ascendingdc.com/services/data-warehouse/): Build high-quality data platforms for enterprise analytics use cases - [Smart Data (AI and ML)](https://ascendingdc.com/services/smart-data/): Apply AI and ML to data for better decisions - [Data Visualization](https://ascendingdc.com/services/data-visualization/): Turn raw data into clear visual insight for decision making - [DataOps](https://ascendingdc.com/services/data-ops/): Automate analytics orchestration with transparent operational metrics - [Cloud Big Data Solution](https://ascendingdc.com/services/big-data/): Scale big data platforms for insight-driven business operations - [DevOps Cloud](https://ascendingdc.com/services/devops-cloud/): AWS DevOps with containers CI/CD and infrastructure as code - [AWS Zero Trust Framework](https://ascendingdc.com/services/zero-trust/): Identity-based security with strict authorization and access controls - [Managed Single Sign-On](https://ascendingdc.com/services/managed-sso/): Cloud-managed SSO that improves security and reduces IT overhead - [CloudFront](https://ascendingdc.com/services/cloud-front/): Accelerate global content delivery with AWS CloudFront distribution - [Embedded Analytics](https://ascendingdc.com/services/quicksight/): Embed QuickSight analytics into applications for monetizable insights Industries: - [Finance and Insurance](https://ascendingdc.com/industries/finance-insurance/): Cloud data and AI services for regulated financial organizations - [Healthcare](https://ascendingdc.com/industries/healthcare/): Modernization and analytics solutions for healthcare transformation initiatives - [Information Technology](https://ascendingdc.com/industries/information-technology/): Cloud and data engineering services for IT organizations - [Media and Entertainment](https://ascendingdc.com/industries/media/): Digital and cloud solutions to improve media customer experiences - [Education](https://ascendingdc.com/industries/education/): Data analytics and system integration for education institutions - [Energy](https://ascendingdc.com/industries/energy/): Analytics automation and AI solutions for energy-sector modernization - [SMB and Startup](https://ascendingdc.com/industries/smb/): Scalable cloud services tailored to startups and SMB teams - [Supply Chain](https://ascendingdc.com/industries/supply-chain/): IoT blockchain AI and ML solutions for supply chain optimization Additional company pages: - [Public Sector Overview](https://ascendingdc.com/public-sector/overview/): Government IT modernization and IT staffing contract vehicles - [Georgia Technology Authority Cloud Engineering Services](https://ascendingdc.com/public-sector/georgia-technology-authority-cloud-engineering-services/): GTA Master Services Agreement GTA-98000-0952026-ASC for cloud architecture, migration, DevSecOps, AI/ML, FinOps, and data engineering - [Case Studies](https://ascendingdc.com/about/case-studies/): Client outcomes across cloud modernization data and AI programs - [Company Overview](https://ascendingdc.com/about/company-overview/): Mission capabilities and enterprise cloud transformation approach ## Company Information - **Website**: https://ascendingdc.com - **Company Overview**: https://ascendingdc.com/about/company-overview/ - **Location**: 2751 Prosperity Avenue, Suite 240, Fairfax, VA 22031-4397 - **Phone**: +1-518-288-7586 - **Email**: support@ascendingdc.com - **Training Portal**: https://training.ascendingdc.com - **Marketplaces**: AWS Marketplace, Azure Marketplace - **LinkedIn**: https://www.linkedin.com/company/ascendingllc - **YouTube**: https://www.youtube.com/@ASCENDINGdc