Jarvis AI
Talent Solutions
Public Sector
About
Contact Us
image

Every Agent. Every Tool.
Governed End to End.

Jarvis enforces identity-based access control, data privacy rules, and registry validation at every invocation - then makes the entire agent execution chain visible through OTEL-native observability and real-time flow tracing.

Jarvis Governed AI platform demo
Governance Pillars

What Governed AI Covers

Six enforcement layers that together ensure no agent invocation happens outside defined identity boundaries, validated registrations, and a complete observable record.

RBAC & ACL

Role-based scopes and per-resource ACL layers define exactly who can invoke which agent or MCP tool. Deny always wins. Policy is defined in the registry and enforced at the gateway in real time.

RBACACLdeny wins

Data Privacy

PII detection, field-level masking, and data residency constraints are applied before payloads reach any agent or tool. Sensitive data never leaves its permitted boundary unredacted.

PII maskingresidency

Registry Validation

Every agent and MCP server must pass the registry's publish gate - security scan, capability validation, and policy compliance - before the gateway will route any invocation to it.

publish gateno shadow AI

OTEL Observability

Protocol-aware OpenTelemetry spans capture every tool call and agent invocation with latency, token usage, and identity context. Export to any OTLP backend.

OTELtrace spans

Egress OAuth

Client credentials stay encrypted at rest. Access tokens are acquired and refreshed automatically so agents authenticate to downstream services without handling credentials directly.

OAuthtoken refresh

IdP Integration

Standard OpenID Connect integration with Okta, Microsoft EntraID, Auth0, Keycloak, Amazon Cognito, and any OIDC-compliant auth server.

OIDCJWT claims
Features

Governance Across Every Layer of Execution

From the moment an identity presents a token to the moment a tool returns a result, every step is governed, validated, and observable.

01 — RBAC Scopes and Resource ACL

RBAC Defines What a Role Can Do. ACL Controls Access Per Resource.

RBAC assigns permissions by function - what actions a role may perform across what resource types.
ACL operates per individual resource - a valid role can still be explicitly denied on a specific agent.
The two layers are complementary: RBAC sets the broad boundary, ACL refines within it.
Deny always wins - no role grant can override an explicit ACL deny on a resource.
RBAC role - sre-engineer
Role permissions - resource type scope
invoke
read schema
manage
sre-engineer
finance-analyst
platform-admin
ACL overrides - diagnosis-agent
marcus.t@coRBAC invoke + ACL allow
jordan.l@coACL deny wins
sarah.w@coRBAC no invoke

02 — Data Privacy

Guardrails Filter Sensitive Data Before It Reaches the LLM

Input guardrails scan the user's message and context before the payload reaches any LLM or agent.
PII fields - SSN, card numbers, email addresses - are redacted or masked inline before forwarding.
Output guardrails filter the LLM's response before it is returned to the caller.
Guardrail rules are configurable per team, namespace, or individual agent endpoint.
guardrail pipeline - request flow
Input guardrails - before LLM
PII Detection & Masking
SSN, cards, and emails are masked inline
on
Topic Policy
Restricted subject matter is blocked
on
Prompt Attack Detection
Injection attempts are stopped early
on
Output guardrails - after LLM
Response PII Scrub
Residual sensitive data is stripped
on
Grounding Check
Unverified claims are flagged
off

03 — Registry Validation

Agent Cards and MCP Tools Validated Against Org Standards Before Any Invocation

Agent card validation enforces required auth type, owner field, and capability schema format.
MCP server registration validates tool definitions, parameter schemas, and allowed resource patterns.
The registry injects org-standard fields when a submitted card is missing required metadata.
Gateway blocks any agent or MCP tool not present and active in the registry - no shadow AI.
registry validation - agent card
Agent card - diagnosis-agent
// submitted card - pre-validation
{
  "name": "diagnosis-agent",
  "version": "2.3.1",
  "owner": "marcus.t@co",
  "auth": null
}
After org-standard injection
// registry-enriched card
{
  "name": "diagnosis-agent",
  "auth": "oauth2-client-credentials",
  "namespace": "sre",
  "status": "pending-scan"
}
MCP tool validationcloudwatch - 10/10 tools
Unregistered agent blockedshadow-agent - 404

04 — OTEL Monitoring

Every Tool Call and Agent Invocation as a Traced Span

Protocol-aware OTEL spans separate agent invocation, MCP tool call, and LLM inference.
Caller identity, policy version, and registry state are captured on every span.
Token usage, latency, and error codes are visible at tool-call granularity.
Export to Datadog, Grafana, Honeycomb, or any OTLP-compatible backend.
otel trace - run_b04c71
ROOTsre-workflow / diagnose538ms
A2Adiagnosis-agent v2.3482ms
LLMclaude-sonnet - 1,842 in - 312 out218ms
MCPcloudwatch / get-metric-statistics104ms
MCPcloudwatch / describe-alarms72ms
MCPgithub / search-issues56ms
A2Aremediation-agent v1.156ms
MCPpagerduty / create-incident22ms

05 — Agent Flow Transparency

Every Agent Workflow Layer Visible as It Runs Through the Gateway

The gateway surfaces the live execution path of any multi-agent workflow in real time.
Each A2A call between agents is a visible, traceable hop.
MCP tool calls within each agent are surfaced individually.
Blocked, failed, or waiting hops are immediately visible.
See the full agent workflow layers in Agent Gateway
live agent flow - via agent gateway
SRE Workflow
caller - RBAC: sre-engineer - policy v5
complete
A2A invoke - gateway auth check
Diagnosis Agent v2.3
registry validated - guardrails active
running
MCP tool call - otel span
CloudWatch MCP
get-metrics - 94ms
complete
CloudWatch MCP
describe-alarms
running
A2A invoke - ACL check
Remediation Agent v1.1
awaiting diagnosis result
waiting

06 — Egress OAuth

Encrypted Credentials, Automatic Token Acquisition and Refresh

OAuth client ID and client secret are stored encrypted at rest.
Access tokens are acquired automatically and injected into outbound requests.
Token refresh is handled proactively before expiry.
One credential store per agent endpoint keeps access scoped, auditable, and revocable.
egress credential store
client_id / client_secret
AES-256 encrypted - never in logs or env vars
encrypted
Access token
Auto-acquired and injected into egress request headers
auto
Token refresh
Proactive refresh before expiry
active
// egress request - injected by gateway
GET /api/resource HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1...
X-Jarvis-Agent: diagnosis-agent/2.3.1
// client_secret never leaves the platform

07 — IdP Integration

Standard OpenID Connect with Any Enterprise Identity Provider

OIDC discovery-based integration points Jarvis at your auth server's well-known endpoint.
JWT claims map to RBAC roles and ACL identities via configurable claim-mapping policy.
Machine-to-machine flows support agent-to-agent and pipeline invocations.
Works with any OIDC-compliant auth server - not limited to a vendor list.
supported identity providers
Okta
OIDC - SAML
ready
Microsoft EntraID
OIDC - Azure AD
ready
Auth0
OIDC - M2M flows
ready
Keycloak
OIDC - self-hosted
ready
Amazon Cognito
OIDC - AWS
ready
Any OIDC auth server
standard discovery doc
custom
Claim mappingJWT claims to RBAC roles & ACL identities
M2M grantclient credentials - audience-scoped JWT

08 — Federation Identity

OIDC-Based Integration with AWS AgentCore and Azure AI Foundry

Adheres to native federation standards of AWS AgentCore and Azure AI Foundry.
Enables RFC-standard auth auto-discovery in MCP servers and A2A agents.
JWT claims map to RBAC roles and ACL identities.
Machine-to-machine flows support agent-to-agent and pipeline invocations.
Works with any OIDC-compliant auth server.
federation identity - agentcore & ai foundry
Federated providers
AWS AgentCore
OIDC - IAM Identity Center - client credentials
connected
Azure AI Foundry
OIDC - EntraID - service principal
connected
RFC auth auto-discovery - MCP & A2A
GET /.well-known/openid-configuration
-> issuer, token_endpoint, jwks_uri

audience: agentcore.amazonaws.com
audience: api.azureml.ms

"groups": ["sre-team"] -> role: sre-engineer
MCP server auth discoveryRFC auto-config
Federated agents inheritRBAC - ACL - audit trail

Federation Identity - AWS AgentCore & Azure AI Foundry

OIDC-based federation with AWS AgentCore and Azure AI Foundry lets agents in those environments authenticate through Jarvis using standard OpenID Connect, inheriting the same RBAC, ACL, and audit trail as natively registered agents. Learn more about AgentCore federation

Ready to Govern Your
Enterprise AI Agents?

See how Jarvis Governed AI brings identity enforcement, data privacy, registry validation, and full observability to every agent and tool invocation in your enterprise.