Docs/Lanes Link/Providers/iCloud Contacts

iCloud Contacts

Connect iCloud Contacts to your agents with Lanes Link. Look up an address over CardDAV.

Search and read contacts in an iCloud address book over CardDAV.

Connect it

console
$ lanes link connect icloud_contacts --profile personal --workspace local

This takes an app password rather than a browser sign-in. One password covers icloud_calendar and icloud_mail as well, because they share a credential. The iCloud guide has the steps for generating one.

Because it needs no browser, an agent with a shell can do the whole setup:

console
$ printf %s "$TOKEN" | lanes link secrets set icloud/main --profile personal
$ lanes link connect icloud_contacts --id main --non-interactive --json --profile personal

Credentials go in on stdin, never as a flag: an argument lands in your shell history, in ps output, and in any transcript.

What your agent can do

CardDAV gives a fixed set of capabilities, the same on every server that speaks it:

  • icloud_contacts.list_addressbooks
  • icloud_contacts.search_contacts
  • icloud_contacts.create_contact

What is recorded

Every call is recorded, allowed or refused. The rule is to keep the shape and withhold the words: an audit log that reproduced the content would be a second copy of the thing it was meant to make accountable.

Identifiers such as addressbook and limit are kept. Everything that carries your words is withheld.

What an entry holds and how to read one is on the audit log.

Narrowing what it may do

Connecting grants the read bundle. Tightening it happens on your machine and takes effect at once:

console
$ lanes link policy deny 'icloud_contacts.*' --connection icloud_contacts.main --profile personal --workspace local

A deny always beats an allow, whatever the order in the file. See Scopes and permissions for widening, and for what can and cannot be set per connection.


Next: every provider, or Connections for what a connection is and the methods behind one.