CydentiCydenti
AI-agent and MCP views: demo / preview

MCP Security

Dedicated AI-agent and MCP views described here are demo/preview scope. Confirm customer availability, connector coverage and permission granularity during evaluation. Existing read-only NHI analysis uses the data exposed by supported connected APIs.

MCP server cube at the centre, linked to an agent fingerprint, a key, a chip, and a human owner, with a risk glow.
Illustrative conceptual diagram; it does not demonstrate connector coverage or customer availability.

What is MCP security?

Model Context Protocol connects clients to tools and resources. Authentication depends on the implementation. Review the actual accounts and grants used, without assuming a SaaS connector reveals every MCP server.

Dedicated views described here are demo/preview scope. They do not guarantee exhaustive discovery, confirmed owners or object-level permissions.

Cydenti is not an MCP gateway and does not sit in the MCP session. Read-only discovery.

Available data, ownership to confirm, access to review

IAM already does this for people. MCP servers skip the queue.

See

Check identities visible in connected APIs. Dedicated MCP inventory is demo/preview scope; local servers may be absent.

Validate ownership

A service account or OAuth application used by an agent may be visible without identifying the agent or its MCP servers. Likely owners require validation. Exhaustive discovery, automatic ownership and object-level permissions are not guaranteed.

Separate duties

One agent should not stack MCP servers that conflict. Tickets on one side. Production code on the other.

A key in a JSON file,
invisible to IAM.

A developer adds a local MCP server for GitHub. Then another for the CRM. The agent answers tickets and pushes code. Nobody named an owner. No segregation-of-duties review.

Local MCP servers can remain outside connected SaaS APIs. Check coverage and missing data before drawing conclusions.

“If the agent is trustworthy, the MCP server can still be the hole. It is the server's credential that opens the door.”

What IAM does not see
Typical MCP servers
  • A named human owner
  • A segregation-of-duties check
  • A rotation date on the key
  • Offboarding when the project dies

What to Verify During Evaluation

Read-only NHI analysis depends on connected data; confirm availability and timing for preview MCP views.

MCP inventory

SaaS APIs do not guarantee MCP-server discovery. Confirm customer availability and coverage for dedicated demo/preview views.

Credential behind the server

The risk is not the protocol. It is the API key, OAuth token, or service account the server uses to talk to the CRM, GitHub, or Slack.

Human owner

Review available ownership context and have your team validate any likely owner. Ownership may remain unknown.

Segregation of duties

Support and code access may merit a joint review. Dedicated cross-service conflict views are demo/preview scope, without a guaranteed shipped enforcement engine.

Actual scope

Permissions and granularity depend on the data exposed by the API and connector. Object-level visibility is not guaranteed.

Tied to the agent

Dedicated agent-to-MCP-server mapping is demo/preview scope. Availability and limitations must be confirmed for your environment.

Illustrative example

One local MCP server, two jobs

An agent named support-copilot has a HubSpot MCP server and a GitHub MCP server on a developer's laptop. It answers tickets. It can also push code. Nobody is named as owner.

Illustrative review scenario, not a customer incident or shipped detection: the team would check exposed identities, confirm owners and review conflicts. Dedicated agent/MCP mapping remains demo/preview scope.

FAQ

What is MCP security?

Reviewing the authentication, permissions and accountable teams for an MCP deployment. Authentication depends on its implementation. A server name alone does not establish which identities or downstream permissions are in use.

Can a SaaS connector discover every MCP server?

No. A connector may expose a service account or OAuth application used in an MCP deployment without identifying the MCP server or its client. Local servers and deployments outside connected APIs may be absent. Dedicated MCP inventory and agent mapping are demo/preview scope; confirm customer availability and coverage.

Does Cydenti replace an MCP gateway?

No. Cydenti analyses available NHI data read-only. It does not issue short-lived runtime credentials, rotate secrets or enforce MCP sessions. Your identity, secrets-management and gateway tools retain those responsibilities.

Are owners and object-level permissions guaranteed?

No. Likely owners must be validated, and ownership may remain unknown. Permission granularity depends on the API, permissions and connector. Agent-to-MCP relationships and dedicated views shown in demos are preview scope, with customer availability to confirm.

What about segregation of duties across MCP connections?

Conflicting access is a review topic for the responsible team. Dedicated cross-service agent/MCP duty-conflict views described here are demo/preview scope, not a claim of a shipped enforcement engine. Your team validates the data and makes approved changes in its existing tools.

Ready to secure your future?

Discover the machine identities you didn't know you had — the first inventory usually lands within a week.

The Audit Flash connects up to three SaaS applications through read-only APIs. Review the service accounts, credential metadata and OAuth grants visible in that scope, then agree which risks your teams should address. Coverage and timing depend on the connected applications and available data. No commitment.

No commitment • No credit card • Data hosted in Europe • Response within 24h

MCP Security: Preview & Coverage | Cydenti