AI Agents Are Platform Users Now - And We're Not Ready

General
1

Last month, my side project’s AI agent burned through $300 in API costs overnight. I woke up to a Slack alert that felt like a punch to the gut. The agent was stuck in a loop, making thousands of OpenAI calls because I’d given it unlimited quota access “just for testing.”

That $300 mistake taught me something bigger: we’re treating AI agents like magic tools when they’re actually autonomous users who need the same governance we give humans.

By the end of 2026, I predict mature platforms will treat agents as first-class citizens - with RBAC, resource quotas, audit trails, and all the boring infrastructure we’ve spent decades building for human users.

We’ve Been Thinking About This Wrong

Here’s the uncomfortable truth: we’ve been bolting agent access onto platforms as an afterthought. Need an AI to read your docs? Just pass it an API key with full access. Want it to create pull requests? Give it admin rights “temporarily.”

This approach worked fine when agents were simple, supervised tools. But the State of AI Agent Security 2026 Report shows we’re past that world:

  • 81% of technical teams are past the planning phase and actively testing or deploying agents in production
  • But only 14.4% have full security approval
  • And 88% confirmed or suspected security incidents this year

That gap between deployment and security approval is terrifying. We’re shipping production agents faster than we’re building the governance infrastructure to manage them.

The Real Platforms Are Launching Now

This isn’t theoretical anymore. Major players are treating 2026 as the year agent governance becomes real infrastructure:

Microsoft Agent 365 (GA on May 1, 2026) provides a control plane that enforces least privilege access, secures agent access to resources, protects sensitive data, and includes threat protection for agents.

Okta for AI Agents (GA on April 30, 2026) introduces Agent Gateway as a centralized control plane to secure AI agent access - they’re calling it the “blueprint for the secure agentic enterprise.”

1Password Unified Access (announced just last week!) gives organizations the ability to discover, secure, and audit agent access at the moment it occurs - treating agents as identities with credentials that need management.

These aren’t vaporware. They’re shipping this quarter.

It’s Not Just Auth - It’s Identity, Resources, and Audit

From my design systems background, I see this as building a “component library” for agent governance. Just like we create reusable UI components with clear APIs and constraints, we need:

Identity: Agents aren’t humans, but they’re also not faceless service accounts. They need distinct identities that can be provisioned, monitored, and revoked. The IETF’s AIMS framework (published this year) composes WIMSE, SPIFFE, and OAuth 2.0 to create a standardized approach.

Resource Quotas: My $300 mistake could’ve been $20k - and according to platform engineering predictions, those high-cost incidents are driving platforms to implement AI-specific budgets for token and inference costs.

Authorization Policies: This is where it gets interesting. AuthZEN became a Final Specification in January 2026, standardizing how Policy Enforcement Points query Policy Decision Points regardless of vendor. It’s the foundation for policy-driven agent authorization.

Audit Trails: When an agent accesses customer data, approves a PR, or makes a financial transaction, we need the same audit trail we’d require for a human with those permissions.

The Design Question Nobody’s Asking

Here’s what keeps me up at night: Are we building agent platforms, or are we adding auth as an afterthought?

Most current approaches feel like the latter. We’re taking human identity patterns (username/password, RBAC roles, session management) and awkwardly applying them to agents. But agents don’t log in. They don’t have sessions. They spawn, execute, and terminate. They need different primitives.

The platforms shipping this month are starting to answer this, but I’m curious whether they’re building the right abstractions or just racing to market with repackaged human identity systems.

Why This Matters for Real Products

I’m building an accessibility audit tool powered by AI agents. The agent crawls websites, identifies WCAG violations, and generates reports. It needs:

  • Read access to client websites (but not modify)
  • Write access to our database (but only for specific client records)
  • API access to external services (but with cost limits)
  • Audit logs that prove we never accessed PII inappropriately

Without mature agent governance, I can’t ship this to enterprise customers. And I know I’m not alone. The lack of production-ready agent platform infrastructure is blocking real innovation.

What Needs to Happen

From where I sit as a practitioner:

  1. Standards adoption: AIMS and AuthZEN are great starts, but we need broad implementation across cloud providers and platform tools
  2. Open-source tooling: The Microsoft/Okta/1Password solutions are valuable but vendor-specific. We need open alternatives.
  3. Cost transparency: Token usage and inference costs need to be first-class platform metrics with alerts, budgets, and quotas built in
  4. Audit by default: Every agent action should generate an immutable audit trail without extra developer effort

The exciting part? This shift is happening right now. Products are launching. Standards are solidifying. The question is whether we build this right or repeat the same security mistakes we made with microservices, containers, and every other infrastructure paradigm shift.

What do you all think? Are your platforms treating agents as first-class users yet? What governance challenges are you running into?

2

@maya_builds This hits incredibly close to home. I lead engineering at a Fortune 500 financial services company, and we’ve been trying to pilot agent-based code review assistants for six months. Compliance has blocked us twice because we couldn’t provide adequate governance answers.

Your $300 overnight story? Our compliance team’s nightmare scenario is exactly that, but with customer PII instead of API costs. If an agent accesses regulated customer data and we can’t produce an audit trail showing exactly what was accessed, when, and why - we’re looking at regulatory penalties that make $20k runaway costs look trivial.

The 88% Security Incident Rate Is Terrifying

That State of AI Agent Security stat you cited - 88% confirmed or suspected security incidents - that’s exactly why financial services is moving so slowly on agents. We can’t afford to be in that 88%.

But here’s the frustration: our competitors who move faster might gain significant operational advantages. There’s real pressure to deploy agents for fraud detection, customer service automation, and risk analysis. The business case is compelling. But without mature governance, we’re stuck.

Standards Give Us Hope

The IETF AIMS framework you mentioned is promising because it’s composing existing standards (SPIFFE, OAuth 2.0) rather than inventing something entirely new. My team is already using SPIFFE for service identity, so building on that foundation makes sense.

The challenge is time. AIMS was just published. AuthZEN became final in January. Microsoft Agent 365 and Okta for AI Agents don’t launch until late April/early May. We need to pilot something in Q2 to hit our innovation goals, but the tooling we’d want to use isn’t generally available yet.

The Specific Problem: Agent Access to Customer PII

Let me make this concrete. Our use case: AI agent analyzes customer transaction patterns to flag potential fraud. This agent needs:

  • Scoped read access: Only transactions for accounts flagged by our initial rule-based system (not all customer data)
  • Temporal access: Access should automatically expire after analysis completes
  • Audit trail: Immutable log showing which customer records were accessed, what was extracted, and what decision was made
  • Revocation: If we discover the agent has been compromised, we need instant access revocation across all systems

Right now, we can’t confidently build this without creating custom governance infrastructure. And custom security infrastructure in financial services gets expensive fast.

Balancing Innovation Speed With Governance

Here’s my question for the group: How do you balance innovation speed with governance requirements when the platforms aren’t quite ready yet?

Do we:

  • Build custom infrastructure now and plan to migrate when standards mature?
  • Wait for Microsoft/Okta solutions to launch and accept the delay?
  • Start with extremely limited pilot scope (isolated environment, synthetic data) to learn while we wait?

I suspect the answer is “all three” but I’m curious what other engineering leaders in regulated industries are doing. @cto_michelle, you’re dealing with compliance in your cloud migration - how are you thinking about agent governance?

The stakes are high. Get this right, and we unlock significant business value. Get it wrong, and we’re explaining to regulators why an AI agent accessed customer financial data without proper controls.

3

@eng_director_luis I appreciate the tag, and your compliance concerns are absolutely valid. But I want to challenge the framing a bit here.

Are Agents Really “Users”? Or Are They Service Accounts 2.0?

@maya_builds, your post makes a compelling case for treating agents as first-class platform citizens, but I’m not convinced “agents as users” is the right mental model. Agents are more like sophisticated service accounts - they’re automated, non-human actors that operate on behalf of systems or users.

The reason this matters: we already have patterns for managing service accounts, and I’m concerned we’re reinventing wheels instead of evolving what works.

Service accounts have identities, scoped permissions, audit trails, and credential rotation policies. The main difference with agents is scale and autonomy. An agent might spawn multiple sub-agents, make decisions based on context, and adapt its behavior dynamically. But conceptually? It’s still automated system access.

The Right Foundation: AuthZEN, Not Microsoft’s Walled Garden

That said, I strongly agree we need better infrastructure. Where I part ways with the current narrative is the solution set.

AuthZEN becoming a Final Specification in January is the real foundation here. It standardizes policy-driven authorization regardless of vendor - any Policy Enforcement Point can query any Policy Decision Point. This is the open standard approach we need.

Compare that to Microsoft Agent 365 - it’s launching May 1st with some compelling features (least privilege access, threat protection, agent-specific controls). But it locks you into Microsoft’s ecosystem. If you’re running agents on AWS or GCP, or using open-source agent frameworks, you’re building integrations on top of a Microsoft-specific control plane.

Same concern with Okta for AI Agents. It’s a comprehensive solution but creates vendor dependency at a critical infrastructure layer.

Quota Management Is The Immediate Priority

Here’s where I align completely with your experiences: cost control is critical and under-addressed.

My team hit $12,000 in unplanned agent costs last quarter. Not from a failure or runaway loop - just from underestimating token consumption at scale when agents are processing real production workloads.

We need:

  • Per-agent spending limits with automatic circuit breakers
  • Cost allocation by team/product/environment
  • Predictive alerts based on usage trends
  • Rate limiting that understands token costs, not just request counts

This is table-stakes infrastructure. The fact that platform engineering predictions for 2026 are calling out “AI-specific budgets for token and inference costs” as a prediction rather than standard practice shows how early we are.

Practical Implementation: Are We Over-Engineering?

@eng_director_luis, to answer your question about balancing speed with governance - I think we might be over-rotating on complexity.

Start with:

  1. Rate limits per agent identity (basic cost control)
  2. Scoped API keys (limit blast radius)
  3. Centralized logging (audit trail foundation)
  4. Manual approval gates for high-risk operations (human-in-the-loop)

This isn’t elegant or automated, but it’s shippable now and lets you start learning. Then evolve toward AuthZEN-based policy engines and proper agent identity management as the tooling matures.

The risk of waiting for Microsoft/Okta to be generally available is that you miss Q2 entirely. The risk of building custom infrastructure is maintenance burden. But starting with proven patterns (rate limits, scoped credentials, logging) and incrementally adding sophistication feels like the pragmatic path.

The Real Challenge: Visibility and Observability

One area that’s genuinely underserved: observability for agent behavior.

Traditional APM tools don’t capture agent-specific patterns well. When an agent makes 50 API calls to accomplish a task, was that efficient? Wasteful? Malicious? Current tooling can’t easily answer that.

Kore.ai’s Agent Management Platform mentions observability as a core capability. I haven’t tested it yet, but the idea of a unified operational layer to monitor agent performance, cost, and security across frameworks is appealing.

We need dashboards that show:

  • Agent success/failure rates by task type
  • Cost per agent per operation
  • Anomaly detection (is this agent behaving abnormally?)
  • Dependency mapping (which agents call which services?)

This visibility unlocks both cost optimization and security monitoring.

Bottom Line

Yes, agents need governance. But let’s not get swept up in the hype of treating them as magical new primitives that require entirely new infrastructure.

They’re automated actors that need identity, authorization, resource limits, and observability. We have patterns for this. Let’s evolve those patterns rather than rebuilding from scratch.

Start pragmatic. Ship incrementally. Adopt standards like AuthZEN rather than locking into vendor ecosystems. And prioritize cost controls because that $20k runaway session will happen faster than you think.

4

This conversation is fascinating from a product strategy perspective, but I’m going to be the voice of uncomfortable reality here: while we’re debating the right governance architecture, competitors are shipping AI features and winning deals.

The Market Reality: AI Features Are Table Stakes in 2026

I’m VP Product at a Series B fintech SaaS company. In the last 6 weeks of customer conversations, here’s what I’m hearing:

  • “Does your platform have AI-powered analysis?” (asked in 11 of 14 sales calls)
  • “Our current vendor just launched AI insights - can you match that?” (3 times)
  • “We’re evaluating vendors specifically on AI capabilities” (twice, from Fortune 500 prospects)

AI isn’t a differentiator anymore - it’s a requirement. Prospects expect it. Existing customers are asking for it. Competitors are launching it.

And here’s the brutal part: customers don’t care about agent RBAC, AuthZEN compliance, or identity frameworks. They care about value delivered, friction removed, and problems solved.

The Product Tension

I completely agree with the technical points being raised. @cto_michelle, your cost control priorities are spot on - $12k in unexpected spend is real money that hits our P&L. @eng_director_luis, your compliance concerns in financial services are absolutely valid.

But from a product lens, I’m balancing:

Customer demand (ship AI features NOW) vs. Governance maturity (wait for proper infrastructure)

Competitive pressure (competitors shipping weekly) vs. Technical prudence (don’t ship insecure agents)

Revenue opportunity ($2M+ in pipeline asking for AI) vs. Operational risk (the 88% security incident rate)

Right now, governance concerns are losing to market pressure. That’s not because we’re reckless - it’s because the cost of not shipping is measurable in lost deals and customer churn.

The 21.9% Stat Feels Wrong

@maya_builds cited that only 21.9% of teams treat agents as independent identity-bearing entities. That number is way too low for where the market is heading.

By end of 2026, I predict 60%+ of B2B SaaS products will have autonomous agent features. Those agents will need to:

  • Access customer data on behalf of users
  • Make decisions and take actions
  • Integrate with third-party systems
  • Operate with varying permission levels

If we’re still treating 80% of those as “extensions of human users” or generic service accounts, we’re building technical debt at scale.

Enterprise vs SMB Gap

One thing I haven’t seen addressed: the solutions shipping this quarter are all enterprise-focused.

Microsoft Agent 365? Requires Microsoft 365 qualifying plans or standalone purchase. That’s enterprise territory.

Okta for AI Agents? Okta’s pricing model skews heavily toward larger organizations.

1Password Unified Access? Same story - this is built for “companies of all sizes” but the feature set and complexity suggest enterprise use cases.

What about the SMB SaaS products serving 50-500 person companies? They need agent governance too, but can’t afford enterprise identity platforms or dedicated security teams.

We need lightweight, developer-friendly solutions that provide baseline governance without requiring a PhD in identity management or a six-figure platform budget.

The Practical Question

Here’s what I asked my engineering team last week: “How do we ship agent features in Q2 while building governance that won’t embarrass us in Q3?”

Their answer was essentially @cto_michelle’s pragmatic approach:

  • Scoped API keys for agents (limits blast radius)
  • Manual approval for high-risk operations (human validation gates)
  • Basic cost limits and alerts (prevent runaway spend)
  • Logging everything (audit trail for later)

It’s not elegant. It’s not AuthZEN-compliant. It won’t win architecture awards.

But it lets us ship AI-powered financial insights to customers next month instead of waiting until Agent 365 launches on May 1st, then spending Q3 integrating it.

Do End Users Even Understand This?

Final thought: I showed a mockup of agent permission settings to 5 customers in user testing sessions.

Their reaction? Confusion.

“Why does the AI need permissions?”
“Isn’t it just analyzing my data that I already have access to?”
“This feels complicated - can’t it just work?”

End users conceptualize AI agents as smart features, not autonomous actors with identity and permissions. The mental model disconnect is real.

This doesn’t mean we skip governance - it means we need to abstract it away. Security should be invisible to users while being comprehensive under the hood.

What I Need From This Community

Honest question for the engineering leaders here: How do I bridge the gap between “ship fast to win deals” and “build proper governance to avoid disasters”?

What’s the minimum viable governance that lets me:

  • Ship agent features in Q2 2026
  • Avoid being in the 88% with security incidents
  • Not accumulate crippling technical debt
  • Maintain upgrade path to proper solutions when they mature

Because right now, I’m getting pressure from sales, customers, and our board to move faster on AI. And “we’re waiting for identity standards to mature” isn’t a compelling answer when competitors are closing deals we’re losing.

5

Reading through this thread, I’m struck by how much we’re focusing on tooling and technology while underplaying the organizational and cultural challenges. @maya_builds is absolutely right that agents need governance, but governance isn’t just technology - it’s people, process, and culture.

This Is a People Problem, Not Just a Tech Problem

I lead engineering at a high-growth EdTech startup (80+ engineers across 6 product teams). We started piloting AI agents last quarter for automated test generation and code review assistance.

The biggest blocker wasn’t tooling - it was answering: Who owns agent identity and governance?

Is it:

  • Platform Engineering? (They own infrastructure and developer experience)
  • Security Team? (They own access control and compliance)
  • Individual Product Teams? (They’re building the features that use agents)
  • Architecture Group? (They own system design standards)

We discovered that without clear ownership, every team made different decisions:

  • One team gave their agent admin access “temporarily” that lasted 3 months
  • Another team built custom auth because they didn’t know we had a standard approach
  • A third team blocked agent adoption entirely because they couldn’t get security approval

Sound familiar? That 45.6% using shared API keys for agent authentication isn’t just a technical antipattern - it’s a symptom of organizational confusion.

The Training and Competency Gap

Here’s something nobody’s talking about: most engineers don’t know how to design for agent identities.

We’re hiring engineers who learned web development, mobile apps, distributed systems, microservices. Agent identity management isn’t in their mental toolkit. It’s not taught in bootcamps or CS programs. It’s not covered in most technical interviews.

So when we ask teams to “build agents with proper governance,” they’re:

  1. Learning what agents can do
  2. Learning how identity frameworks work
  3. Learning our company’s security requirements
  4. Learning which tools to use
  5. Trying to ship features on deadline

That’s too much cognitive load. We need to reduce the complexity and provide clear patterns.

Our Approach: Service Accounts + PR Reviews + Training

@cto_michelle’s pragmatic approach resonates, but I want to add the people layer:

Technical Implementation:

  • Agents run as service accounts with scoped permissions (following least privilege)
  • Every PR that creates or modifies an agent requires security team approval
  • Cost limits are mandatory (no exceptions for “testing”)
  • Centralized logging with alerts on anomalous behavior

Organizational Implementation:

  • Platform team provides agent scaffolding templates (right defaults out of the box)
  • Security team maintains agent design patterns documentation
  • Monthly “Agent Security” training for engineers working with AI
  • Clear escalation path: if you don’t know how to implement agent auth, there’s a #agent-security Slack channel with designated responders

Cultural Implementation:

  • Agent security incidents are blameless postmortems (we want people to report issues, not hide them)
  • Security approval isn’t a blocker - it’s a 24-hour SLA with defined criteria
  • Engineering managers review agent governance in 1:1s with their teams

This isn’t perfect, but it acknowledges that technology alone won’t solve governance if the organization doesn’t know how to use it.

Observability Is Underrated

@cto_michelle mentioned observability and I want to emphasize this because it’s both a technical and cultural requirement.

Kore.ai’s Agent Management Platform positions observability as a core capability alongside governance. That’s the right intuition.

We need visibility into:

  • What agents are doing (operational transparency)
  • How they’re performing (success rates, failure modes)
  • What they’re costing (resource consumption)
  • How they’re behaving (anomaly detection)

But here’s the organizational insight: this visibility needs to be accessible to product managers and engineering leaders, not just platform teams.

When @product_david asks “how do we ship fast while building governance?”, part of the answer is: ship with visibility so you can learn and respond quickly when things go wrong.

If an agent starts behaving anomalously, you need dashboards that alert the right people and provide enough context to diagnose the issue. That’s both tooling (APM, logging, metrics) and process (who gets paged? what’s the runbook?).

Career Development Question

Here’s a question I’ve been wrestling with: Do we need “Agent Security Engineer” as a distinct role?

The skill set required:

  • Identity and access management expertise
  • AI/ML understanding (how agents behave)
  • Security architecture
  • Cost optimization
  • Developer experience design

That’s not a typical combination. Right now, we’re asking platform engineers to learn security, security engineers to learn AI, and everyone to figure out cost optimization on the fly.

Maybe the answer is specialized roles. Maybe it’s upskilling existing engineers. Maybe it’s third-party consultants.

But the 88% security incident rate suggests we don’t have enough people with the right competencies yet.

The Cultural Shift

@maya_builds framed this as “agents are platform users now” - I’d extend that to “agents are organizational actors now.”

Just like we had to teach engineering organizations to think about:

  • Service-oriented architecture (early 2000s)
  • DevOps and continuous delivery (2010s)
  • Cloud-native and infrastructure as code (late 2010s)

We now need to teach them to think about autonomous agents as first-class participants in our systems.

That’s a cultural shift. It requires:

  • Updated mental models (agents aren’t just tools)
  • New design patterns (identity, authorization, observability for non-human actors)
  • Organizational clarity (who owns agent governance?)
  • Competency development (training engineers on agent security)
  • Process evolution (how do agents fit into SDLC, compliance, incident response?)

Practical Advice for @product_david

You asked how to bridge “ship fast” and “build governance.” Here’s my framework:

Phase 1 (Now - Q2 2026): Ship with Guardrails

  • Scoped service accounts for agents (limit blast radius)
  • Manual approval gates for high-risk operations (human validation)
  • Cost budgets with automatic shutoff (prevent runaway spend)
  • Comprehensive logging (build audit trail for later)
  • Dedicated on-call for agent incidents (fast response when things break)

Phase 2 (Q3 2026): Mature Governance

Phase 3 (Q4 2026+): Scale and Optimize

  • Agent governance as code (infrastructure patterns)
  • Self-service agent provisioning (developer experience)
  • Advanced anomaly detection (ML-powered security monitoring)

This gives you a path to ship now while building toward mature governance later. The key is treating Phase 1 as a deliberate stepping stone, not technical debt you’ll regret.

But none of this works if we only think about technology. We need to invest equally in organizational design, training, and culture. Otherwise, we’ll have beautiful agent identity frameworks that nobody knows how to use correctly.